From jalocha@home-gate.ifj.edu.pl Sat Apr 01 06:27:49 1995 

Received: from home-gate.ifj.edu.pl ([192.86.14.17]) by dingus.n5lyt.datarace.com 

(8.6.10/8.6.9) with SMTP id GAA18997 for <hfsig@tapr.org>; Sat, 1 Apr 1995 

06:27:36 -0600 

Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP 
id AA2140 ; Sat, 01 Apr 95 14:27:12 UTC 

Date: Sat, 1 Apr 95 13:52:21 MET 

From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl> 

Message-ID: <357.jalocha@home.ifj.edu.pl> 

To: hfsig@tapr.org 

Reply-to: jalocha@home-gate.ifj.edu.pl 

Subject: Parallel carrier modem 


Hello everybody, 


At last I can report a success: I became less ambitious :-) 

and let my parallel carrier modem do only BPSK on every carrier. 
The whole thing began to work ! At least it passes right varying 
bit patterns and the symbol clock converges right. 


The modem runs now at 9600 Hz sampling, 128 point FFT with sin()%2 
window at Tx and Rx. FFT steps are 32 samples with +/- 1 adjustments 
for the receiver to synchronize it to the symbol clock. 

Data carriers are spaced 150 Hz apart. Each carrier is BPSK modulated 
with symbols (bits) spaced by 64 samples which makes 150 bits/sec. 
There are 15 carriers: the first at 600 Hz and the last at 2700 Hz. 
Total data rate is 2250 bps. No FEC coding yet. 

Is this worth anything ? 


Most of the above parameters can be easily adjusted: I can move 
to 256 point FFT and 31 carriers immediately - more carriers very 
likely need some tricks as I will run into my RAM limits. 


The symbol timing and data carrier detection logic work somehow 
although they need some tuning still. I have two different ideas 
about how to make a tuning indicator - one of them must work :-). 

In a short time I should have something useable for on-air operation. 


I suspect there are still minor problems with inter-symbol crosstalks... 
The way I attempt to cancel them is not the best one. 

I could cure the problem by spacing the carriers by more Hz 

- use every third carrier not every second. 

The price: less carriers -> lower total bit rate. 


Paul and others are certainly right that my carrier configuration 
is too tide for an SSB tranceiver. But moving to 8000 Hz sampling 
is not a problem - just one line in the source code. 

Or I just use less carriers, although 15 or 31 carriers 

is a good number for my primitive FEC code. 

24 is good for the Golay code. 


At same time I am thinking about the non-coherent modulation, 
and I can't see a good solution for the problem of finding 


the threshold for 0/1 decisions. With BPSK the threshold is zero 
regardless of carrier's amplitude, for carrier on/off modulation 
the threshold can be potentially different for every carrier. 


Pawel 


From jalocha@home-gate.ifj.edu.pl Sat Apr 01 07:35:53 1995 

Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA19225 for 

<hfsig@tapr.org>; Sat, 1 Apr 1995 07:35:45 -0600 

Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP 
id AA2145 ; Sat, 01 Apr 95 15:35:16 UTC 

Date: Sat, 1 Apr 95 15:08:35 MET 

From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl> 

Message-ID: <361.jalocha@home.ifj.edu.pl> 

To: hfsig <hfsig@tapr.org> 

Reply-to: jalocha@home-gate.ifj.edu.pl 

Subject: Re: [HFSIG:350] Overlapped Symbol windowing (Was HFSIG Activities) 


Hello Paul, 


The result of adding 128pt sin()*2 shaped symbols, overlapped at 64 pts, of 

alternating phases (+/-90degrees = 180degree shifted) is the same as a 64pt 

sin() shaped signal. (Unless there is no phase shift which gives continuous 

tone). This is what my simulations produced. Is this correct, or Do I have a 
flaw in my data? 


VV VV V 


I think what you find is right. 
I try to explain the point by the following (a bit naive) comparison: 


shaping #1: 128 pt, sin()%2 


bit pattern waveform bandwidth 
0101010101 carrier*xsin(2*«pix (1/128) «t) 2* (1/128) 
1111111111 pure carrier 0 


or 000000000 


shaping #2: 64 pt, sin() 


bit pattern waveform bandwidth 
0101010101 carrier*xsin(2*«pix (1/128) «t) 2x (1/128) 
1111111111 carrierxabs(sin(2*pix(1/128)*t)) infinite ! (or at least 


or 000000000 very large) 


As you see the 64pt, sin() shaping generates a very wide signal 


for a constant bit pattern thus you cannot say, that your energy 
goes into the band assigned for that carrier. 
The harmonics (due to "abs" function) will affect other carriers. 


Also, By shaping the symbols so that they are timewise independent, we may be 
able to use multiple phases when the channel is better, thus doubling 
(4phases=2bits) or tripling (8phases=3bits) or data rate? Although the protocol 
would have to detect and adjust for this? 


VVV MV 


I agree the 64pt sin() shaping makes the symbols time-independent, 
but at the price of the bandwidth (thus frequency dependence). 
Here is the comprimise to be taken... 


Pawel 


From karn@qualcomm.com Sat Apr 01 15:01:46 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA20920 for 
<hfsig@tapr.org>; Sat, 1 Apr 1995 15:01:43 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id NAA28192; 
Sat, 1 Apr 1995 13:04:31 -0800 

Date: Sat, 1 Apr 1995 13:04:31 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199504012104 .NAA28192@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <357.jalocha@home.ifj.edu.pl> 

Subject: Re: [HFSIG:351] Parallel carrier modem 


>At same time I am thinking about the non-coherent modulation, 
>and I can't see a good solution for the problem of finding 

>the threshold for 0/1 decisions. With BPSK the threshold is zero 
>regardless of carrier's amplitude, for carrier on/off modulation 
>the threshold can be potentially different for every carrier. 


This is only a problem with on-off keying, it is not inherent to 
non-coherent demoduation. Ordinary FSK is noncoherent, for example. 

So is m-ary FSK. You just look for the filter output with the greatest 
amplitude. 


Phil 


From jalocha@home-gate.ifj.edu.pl Sat Apr 01 18:55:00 1995 

Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id SAA21933 for 

<hfsig@tapr.org>; Sat, 1 Apr 1995 18:54:10 -0600 

Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP 
id AA2149 ; Sun, 02 Apr 95 03:53:10 UTC 

Date: Sun, 2 Apr 95 02:16:07 MET 

From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl> 

Message-ID: <364.jalocha@home.ifj.edu.pl> 

To: hfsig <hfsig@tapr.org> 

Reply-to: jalocha@home-gate.ifj.edu.pl 

Subject: [HFSIG:353] Re: Parallel carrier modem 


Phil wrote: 


This is only a problem with on-off keying, it is not inherent to 
non-coherent demoduation. Ordinary FSK is noncoherent, for example. 

So is m-ary FSK. You just look for the filter output with the greatest 
amplitude. 


VVNV NV 


Right, but only if you take the assumption that your passband is flat. 
I can see several reasons for the passband to be non-flat within 

at least 6dB thus a "take the highest" decision may not be always 
optimal. Ideally, you would monitor the levels on every carrier 

and compute individual thresholds. 

On the other hand I don't like the m-ary FSK as if somebody 

puts on a dead carrier the whole trasmition is trashed. 


Which way would you suggest for Walsh function type signaling 
where you get many carriers turned on at a time ? 


Pawel 


From karn@qualcomm.com Mon Apr 03 01:06:40 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id BAA28917 for 
<hfsig@tapr.org>; Mon, 3 Apr 1995 01:06:37 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id XAA01986; 
Sun, 2 Apr 1995 23:09:25 -0700 

Date: Sun, 2 Apr 1995 23:09:25 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199504030609. XAA01986@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <364.jalocha@home.ifj.edu.pl> 

Subject: Re: [HFSIG:354] Re: Parallel carrier modem 


>Right, but only if you take the assumption that your passband is flat. 
So correct it if it's not flat. This is not a hard problem. 


>On the other hand I don't like the m-ary FSK as if somebody 
>puts on a dead carrier the whole trasmition is trashed. 


Not at all. I have been thinking about this exact problem, and it turns out 
that there's a simple solution. 


First, scramble your data. That ensures that the probability of two 
consecutive symbols (frequencies) being the same is 1/N, where N is the 
number of distinct symbols/frequencies. 


Second, the demod "copies behind". That is, it keeps a history of 
several symbols worth of FFTs. If it sees a consistent strong signal 
in one frequency bin, it attributes it to a strong in-band jammer and 
ignores that channel until it disappears. I.e., it picks the 
next-strongest channel as its output. 


No real problem if the desired signal happens to hit on the jammer's 
frequency since this will only happen with probability 1/N. Just pick 
a FEC code strong enough to correct this many errors. 


My thinking here is that with this scheme for suppressing 
interference, the Walsh function layer may turn out to be unnecessary. 


Proper choice of a window for the FFT will be important, 

though. Rejecting a very strong inband CW interferer requires a window 
with low sidelobes, but windows with this property also broaden the 
mainlobe. This may mean more bandwidth than would otherwise be 
required for 1/T orthogonality. 


Phil 

From JALOCHA@chopin.ifj.edu.pl Wed Apr 05 07:29:00 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAA14399 for 
<hfsig@tapr.org>; Wed, 5 Apr 1995 07:28:45 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id OAA29418 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Apr 1995 14:25:56 +0200 

Date: Wed, 5 Apr 1995 14:27 GMT+1 

Subject: Re: [HFSIG:355] Re: Parallel carrier modem 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <E9DDF4DCOOA038C3@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>Second, the demod "copies behind". That is, it keeps a history of 
>several symbols worth of FFTs. If it sees a consistent strong signal 
>in one frequency bin, it attributes it to a strong in-band jammer and 
>ignores that channel until it disappears. I.e., it picks the 
>next-strongest channel as its output. 


OK, but the algorythm should be enchanced so it can pick up more than one 
jammer :-) 


Walsh function approach looks efficiant to me in this respect: if I have 
128 or 256 carriers I can remove say 4 strongest ones and still be able 
to decode the symbol. An alternative approach would be to compute the 
average of all carriers and then remove carriers above 3 times the 
average or So. 


Pawel 

From JALOCHA@chopin.ifj.edu.pl Wed Apr 05 08:05:48 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA14508 for 
<hfsig@tapr.org>; Wed, 5 Apr 1995 08:04:58 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 


kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA29775 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Apr 1995 15:02:22 +0200 
Date: Wed, 5 Apr 1995 15:03 GMT+1 

Subject: Re: [HFSIG:351] Parallel carrier modem 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <EEEFB45ECOA038C3@chopin.ifj.edu.pl> 
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


It's time to say something about my progress with the parallel-carrier 
BPSK modem: 


The design of using minimal carrier spacing turned out to be 

rather unstable. It did work but crosstalks across time and frequency 
made the symbol-sync not very stable in low S/N. 

My attempts to cancel the crosstalk made the symbol-sync 

even less stable... 


So I decided to use every third carrier, not every second one. 
In such configuration, with sin(x)*2 window the crosstalk across 
carriers is zero. There is still left a crosstalk of 1/6 across 
symbols on same carrier, but the modem was behaving far better 

- I can say it was "useable". 


So now the modem does 8000 Hz sampling, 128 point FFT. 

Data carriers are spaced at 3*(8000/128) = 187.5 Hz 

each carrier is modulated with BPSK at 125 bps (64 points 
between symbols). 

I use 12 carriers which fit into the "standard" audio passband. 


I am playing with two shaping windows (Tx and Rx use identical windows) : 


1. sin(x)42, x=0..pi 
=> freq. crosstalk = 0, time crosstalk=1/6 


2. 3/4xsin(x) -1/4*sin(3*x), x=0..pi 
=> freq. crosstalk = 1/20, time crosstalk=1.7/20 


The second window works a bit better. 
I don't try any more canceling the crosstalks - I just leave it as it is. 


I tested the modem only in loopback mode. To check the behaviour in low 
S/N I was adding some noise from my HF receiver phone-jack. 

The bit-sync and DCD is stable up to very low S/N when you can hardly hear 
the tones in the noise. 

I have made up a KISS interface to the modem so now it is a useable 

KISS TNC. Somebody willing to play with it ? Note that the modem works 

on a DSPCARD4. 


I still see a little problem with symbol-sync: it's a bit slow 
and needs TxDelay time of about 50 (500 ms). 


I tried to come back to QPSK with "every third carrier design": 
the bit-sync locks up and the data looks almost OK but there 
are single flipped bit. 


I plan to double the number of carriers to 24 and then add a Golay FEC code 
with interleave to see how it improves the copy. 

I only need to write Golay routines which don't take up too much space 

for decoding tables, so it all fits into my DSPCARD4 RAM. 


Pawel 

From karn@qualcomm.com Wed Apr 05 12:54:45 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA17309 for 
<hfsig@tapr.org>; Wed, 5 Apr 1995 12:54:40 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id KAA06366; 
Wed, 5 Apr 1995 10:57:28 -0700 

Date: Wed, 5 Apr 1995 10:57:28 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199504051757 .KAAQ6366@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <E9DDF4DCOOAO38C3@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl) 
Subject: Re: [HFSIG:356] Re: Parallel carrier modem 


The algorithm is easily extended to handle several strong jammers, limited 
by two things: the FFT window sidelobes and the strength of the FEC. 


Phil 

From jalocha@home-gate.ifj.edu.pl Mon Apr 10 10:39:11 1995 

Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id KAA24941 for 

<hfsig@tapr.org>; Mon, 10 Apr 1995 10:38:43 -0500 

Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP 
id AA2257 ; Mon, 10 Apr 95 18:38:23 UTC 

Date: Mon, 10 Apr 95 17:37:20 MET 

From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl> 

Message-ID: <310.jalocha@home.ifj.edu.pl> 

To: hfsig@tapr.org 

Reply-to: jalocha@home-gate.ifj.edu.pl 

Subject: Proposal for a picollo-type modulation scheme 


Last weekend I was doing some calculations about the performance 
of various modulations and the picollo-type modulation came out 
to be a clear winner. My thoughts drifted towards m-ary FSK 

and I have here a proposition for a picollo system: 


I am bounded to my DSP system so just to £i1x some numbers 
and to show the relations between them here is the characteristic 
of the FFT which is the base for modulator/demodulator: 


Sampling rate: 8000 Hz. 

FFT size: 256 samples -> 128 frequency bins. 

FFT window: sin(x)42 for x = 0..pi. 

FFT would be done in overlaping steps of 64 samples 


Symbol length = 256 samples 

Inter-symbol spacing = 128 samples (crosstalk = 1/6). 

Symbol rate = 8000/128 = 62.5 Hz 

Inter-carrier spacing = 2 freq. bins (crosstalk = 1/6) = 2*(8000/256) = 62.5 Hz 
Carriers used: 32 - > total bandwitdh = 32*2*(8000/256) = 2000 Hz. 

Bits per symbol: 5 -> raw bit rate = 5*62.5 = 375 bps. 


Tuning is a real problem with these HF modems. 

If you get a radio with 1Hz resolution and stability this may seem not 

to be a problem but at least with my rig which has the tuning resolution 
of 10Hz and the stability of +/- 50-100 Hz this is a problem. 

Even making a tuning indicator which tells you the de-tune within a single 
carrier is not enough is most cases. 


To let the receiver auto-tune to the incoming signal at the beginning 
of a transmition we send a special signal: a ramp-up followed by 


a ramp-down, like this: (an example for 8 carriers) 


Carrier 


OrRPNWAHROON — 
+ 
+ 


01234567 -------- > symbol 


For my FFT setup with 32 carriers this would take 63 symbols 
which is a bit more than one second. 


The receiver would hunt for ramp-up and ramp-down at same time 
and if a coincidence of both is found within the expected time 
the receiver is able to determine the band edges. 


Note that the Rx doesn't need to find a complete ramp to determine 
the edges, it's enough if it finds one piece of the ramp-up 

and another piece of the ramp-down. 

Because the ramps span the whole band there is minimal chance 

that narrowband interferences would prevent the receiver 

from detecting and measuring them. 


Not only the band edges can be determined but the symbol timing 
can be found as well. Thus after detecting the sync. signal 
we are tuned and synchronized. 


We can use the sync. for one more purpose: 

to fix the FEC block timing. Our FEC coding needs the data to be sent 
in blocks thus the receiver should know where are the block's edges. 
The moment when the ramp changes the direction can be considered 

as the mark point: 32 symbols later, when the ramp-down is complete, 


the first FEC block would start. 


The sync. signal could be repeated several times if needed. 

In this case a nice size for the FEC block would be 2*32 = 64 symbols 
(this makes 320 bits or 40 bytes) - then whatever sync. 

we acquire, we will get synchronized to the FEC block timing. 


Infact, this ramp-up, ramp-down series can be the base for the "scrambling" 
algorythm. That is if we send all zeros (NULL characters), the sygnal 
follows this series. 


As you see from my FFT characteristics I "oversample" the signal by two 

both in time and in frequency. I think it should be possible to interpolate 
the points if we found that we are de-tuned by half or a quarter of a carrier. 
Same about the symbol timing shift. This should save the trouble with making 
the sliding FFT with time-adjust capability. 


The way to hunt for ramps: I am going to try summing up energies 
along diagonals, like this: 


Carrier 

| 

7 abc 

- abc 

6 abc 

- abc 

5 abc 

- abc 

4 abc 

- abc 

3 abc 

- abc 

2 abc 

- abc 

1 abc 

- abc 

@ abc 
Q-1-2-3-4-5-6-7 -------- > symbol 


= the "oversampled" points. 

a" = points to be summed into A 
points to be summed into B 
points to be summed into C 


oo 
nou 


If I find B>noise and B>A and B>C I assume the ramp-up is around B 
and I get it's fine position Tu but interpolating with A and C. 


Similar way for ramp-down: I find it's fine time Td. 
If I see Td - Tu = 8 symbols (+/-tune-error) I compute: 


Tu := Tu + 8 Symbols 
Tune_correction = (Tu - Td)/2 


Symbol_time = (Tu + Td)/2 
Little associated ideas: 


- Use Gray code - in a rather probable case that a particular symbol 
"moves" to the adjacent carrier due to receiver mistune or instability 
or the Doppler shift or anything, this will result in corruption 

on one bit only. 


- Band equalization: I think it is enough to adjust the gains for every 
frequency bin such that the RMS of the outcoming signal is same 

for all bins. This should minimize destructive effects coming from 

dead carriers and CWs. 


So what do others think of the whole idea ? 


I am going to write some code for detecting the sync. to see how it 
behaves with low S/N. 


Pawel 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Mon Apr 10 11:41:43 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA25468 for 
<hfsig@tapr.org>; Mon, 10 Apr 1995 11:41:26 -0500 
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th- 
darmstadt.de with SMTP id AA33953 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 10 Apr 1995 18:40:57 +0200 
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus 
(8.6.9/8.6.9-HRZ) with ESMTP id SAA21605 for <hfsig@tapr.org>; Mon, 10 Apr 1995 
18:40:56 +0200 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id SAA21519 for 
hfsig@tapr.org; Mon, 10 Apr 1995 18:36:48 +0200 
Message-Id: <199504101636.SAA21519@hades> 
Subject: Re: [HFSIG:359] Proposal for a picollo-type modulation scheme 
To: hfsig@tapr.org 
Date: Mon, 10 Apr 1995 18:36:48 +0200 (MESZ) 
In-Reply-To: <310.jalocha@home.ifj.edu.pl> from "Pawel Jalocha" at Apr 10, 95 
10:45:05 am 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 3349 


Pawel wrote: 

> 

> Last weekend I was doing some calculations about the performance 
> of various modulations and the picollo-type modulation came out 


> to be a clear winner. My thoughts drifted towards m-ary FSK 
> and I have here a proposition for a picollo system: 


I is clear that m-ary FSK is better than i.e. OFDM, but you trade 
bandwidth for S/N. I believe that a modulation scheme with parallel 
orthogonal carriers (OFDM) and a decent coding will be better in 
overall performance (taking into account that the symbol time is 
limited to about 10ms due to multipath and thus to achieve high 
bitrate you have to use many many carriers in MFSK). 


I am bounded to my DSP system so just to fix some numbers 
and to show the relations between them here is the characteristic 
of the FFT which is the base for modulator/demodulator: 


Sampling rate: 8000 Hz. 

FFT size: 256 samples -> 128 frequency bins. 

FFT window: sin(x)42 for x = @..pi. 

FFT would be done in overlaping steps of 64 samples 

Symbol length = 256 samples 

Inter-symbol spacing = 128 samples (crosstalk = 1/6). 

Symbol rate = 8000/128 = 62.5 Hz 

Inter-carrier spacing = 2 freq. bins (crosstalk = 1/6) = 2*(8000/256) = 62.5 Hz 
Carriers used: 32 - > total bandwitdh = 32*2*«(8000/256) = 2000 Hz. 

Bits per symbol: 5 -> raw bit rate = 5*62.5 = 375 bps. 


VV VV VV VV VV VV VV WV 


With 32 carriers and 4DQPSK on each of them you would have 4000bps. Of 
course the S/N would degrade the performance of such a modulation scheme, 
I think you can win back a lot with coding. But to occupy a whole SSB 
channel for 375bps uncoded data is too inefficient. 


The next problem is the robustness of such a system. I believe if one or 
more frequency bins fade out because of frequency selective fading you are 
in trouble. You would at least have to do some kind of interleaving to 
overcome these effects. 


In the OFDM case we have several possible solutions. If we know the channel 
capacity of each bin or carrier there is a solution (water pouring) how 

to distribute the transmit power over the carriers. This implies that there 
is some back channel from the demodulator at the RX side to the TX side. This 
is possible in an ARQ system. If there is no such channel it is still 
possible to achieve a reasonable throughput by interleaving the information 
on the carriers, so that each virtual "carrier" carries the same mean 
information. 

The third possibility is the application of broadband signals, OCDM 

(= orthogonal code division multiplex). I've read through an interesting 
article on this topic recently (J. Lindner, "Channel Coding and Modulation 
for Transmission over Multipath Channels", to be published in 

no. 3 AEUe, May 1995). 


Alexander 


Alexander F. Kurpiers 

Institut fuer Uebertragungstechnik 

Merckstrasse 25 

D-64283 Darmstadt (Germany) 

Voice: +49-6151-162369 

Fax : +49-6151-165545 

EMail: kurpiers@zeus.uet.e-technik.th-darmstadt.de 
Hamradio: dl8aau@dbO0kg.#nds.deu.eu 
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Subject: Re: [HFSIG:360] Re: Proposal for a picollo-type modulation 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <71FC914213E@frl.orst.edu> 
Hi, 

My $0.02: 

Alexander wrote: 


] 

]Pawel wrote: 

]> 

]> Last weekend I was doing some calculations about the performance 
]> of various modulations and the picollo-type modulation came out 
]> to be a clear winner. My thoughts drifted towards m-ary FSK 

]> and I have here a proposition for a picollo system: 

] 

JI is clear that m-ary FSK is better than i.e. OFDM, but you trade 
]bandwidth for S/N. I believe that a modulation scheme with parallel 
Jorthogonal carriers (OFDM) and a decent coding will be better in 
Joverall performance (taking into account that the symbol time is 
]jlimited to about 10ms due to multipath and thus to achieve high 
]bitrate you have to use many many carriers in MFSK). 

] 

]> 


]> I am bounded to my DSP system so just to fix some numbers 

]> and to show the relations between them here is the characteristic 

]> of the FFT which is the base for modulator/demodulator: 

|> 

]> Sampling rate: 8000 Hz. 

]> FFT size: 256 samples -> 128 frequency bins. 

]> FFT window: sin(x)*2 for x = 0..pi. 

]> FFT would be done in overlaping steps of 64 samples 

]> Symbol length = 256 samples 

]> Inter-symbol spacing = 128 samples (crosstalk = 1/6). 

]> Symbol rate = 8000/128 = 62.5 Hz 

]> Inter-carrier spacing = 2 freq. bins (crosstalk = 1/6) = 2*(8000/256) = 
62.5 Hz 

]> Carriers used: 32 - > total bandwitdh = 32*2x(8000/256) = 2000 Hz. 

]> Bits per symbol: 5 -> raw bit rate = 5*62.5 = 375 bps. 

] 

JWith 32 carriers and 4DQPSK on each of them you would have 4000bps. Of 
]course the S/N would degrade the performance of such a modulation scheme, 
]I think you can win back a lot with coding. But to occupy a whole SSB 
]Jchannel for 375bps uncoded data is too inefficient. 

] 

]The next problem is the robustness of such a system. I believe if one or 
]more frequency bins fade out because of frequency selective fading you are 
Jin trouble. You would at least have to do some kind of interleaving to 
Jovercome these effects. 


] 


Agreed: If we want to take advantage of reasonable conditions, 
especially for networking, OFDM with appropiate coding 
would be great. 


On the other hand, if we are interested in HF communications, no 
matter how adverse conditions may be, MFSK probably would be 
a better choice. 


Implementation of a resonable number of frequency slots, either 

for OFDM or MFSK may require a careful tradeoff in your algorithmic 
approach. I suspect there are further considerations when choosing 
between a correlator appoach, as typically used for MFSK, or the 

FFT approach as typically used by the OFDM. It is my opinion 

that the simplicity of a well-designed correlator, i.e., taking 
advantage of decimated pre-processing, integrate/dump, and precision 
combiners, is Superior in performance to an FFT approach - judged 
merely by roundoff errors and possible dynamic range. The catch is 
that such a correlator takes a lot more code and cannot compete with 
the efficiency of the FFT approach when it comes to a multitude of 
channels. 


My guess, at least when considering our present fixed point DSP's 
is that MFSK will be limited to fewer channels - OFDM will handle 
more channels, however, will not be as robust. 


I think that there is merit for both approaches and would 
encourage experimentation in either - who knows, perhaps there is 
someone out there that has a solution to increasing the dynamic 
range of the FFT approach, or someone that have a solution 

to implementing efficient correlators over a multitude of 
channels. In my modest opinion, those are our present challenges. 


]In the OFDM case we have several possible solutions. If we know the channel 
]capacity of each bin or carrier there is a solution (water pouring) how 

]to distribute the transmit power over the carriers. This implies that there 
jis some back channel from the demodulator at the RX side to the TX side. 
This 

jis possible in an ARQ system. If there is no such channel it is still 
]possible to achieve a reasonable throughput by interleaving the information 
Jon the carriers, so that each virtual "carrier" carries the same mean 
Jinformation. 


]The third possibility is the application of broadband signals, OCDM 

](= orthogonal code division multiplex). I've read through an interesting 
Jarticle on this topic recently (J. Lindner, "Channel Coding and Modulation 
]for Transmission over Multipath Channels", to be published in 

]no. 3 AEUe, May 1995). 


Alexander, perhaps you could give us a summary of what this 
involves - thanks. 


73's, Johan KC7WW 
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Date: Tue, 11 Apr 1995 10:07:37 +0100 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: hfsig@tapr.org 

Subject: Re: Proposal for a picollo-type modulation 

Cc: nash@camail.ca.nmp.nokia.com 


Alexander wrote: 


>I is clear that m-ary FSK is better than i.e. OFDM, but you trade 
>bandwidth for S/N. I believe that a modulation scheme with parallel 


>orthogonal carriers (OFDM) and a decent coding will be better in 
>overall performance (taking into account that the symbol time is 
>limited to about 10ms due to multipath and thus to achieve high 

>bitrate you have to use many many carriers in MFSK). 


My opinion is that MFSK is the optimum choice for single HF channel working, 
low-speed data. OFDM is for higher speed working. Both systems need to be 
developed. Perhaps OFDM could be made to degenerate gracefully towards MFSK 
in worsening channel conditions. If we think of OFDM as a number of 
multiplexed MFSK channels, then these channels could be made to drop out 

so that the same transmitter power becomes concentrated across a smaller 
bandwidth thus gaining SNR. 


Johan wrote: 


Implementation of a resonable number of frequency slots, either 

for OFDM or MFSK may require a careful tradeoff in your algorithmic 
approach. I suspect there are further considerations when choosing 
between a correlator appoach, as typically used for MFSK, or the 

FFT approach as typically used by the OFDM. It is my opinion 

that the simplicity of a well-designed correlator, i.e., taking 
advantage of decimated pre-processing, integrate/dump, and precision 
combiners, is superior in performance to an FFT approach - judged 
merely by roundoff errors and possible dynamic range. The catch is 
that such a correlator takes a lot more code and cannot compete with 
the efficiency of the FFT approach when it comes to a multitude of 
channels. 


VVVVV VV VV VV WV 


I have substituted a quadrature matched correlator type demodulator for the 
FFT-based demodulator in my ADSP2101 MFSK modem and so far have found that the 
Block Floating Point FFT with multiple stages of decimation is better. I do 
the post-integration arithmetic in full floating point. I am not yet clear 

as to why the correlator seems worse. The peak frequency bin is currently 
selected by scanning the array of magnitude squared results, comparing 

first the exponents of M(n), Mpeak, and setting Mpeak=M(n) if M(n)'s exponent 
is greater. If the exponents are the same, the mantissas are compared ina 
similar way. Perhaps this is not the best way of doing it. Any suggestions? 


These are the figures for the matched correlator demodulator: 


Input sample rate: 7680Hz 

Input filter: 45 tap FIR fc=660Hz 

Decimation: 1/3 

Correlator sample rate: 2560Hz 

sin/cos lookup table: 256 entries (FTF=10Hz) 

frame buffer size: 128 (50ms) 

M correlators (M is typically 12) executed at 320Hz rate (16 x per 50ms symbol) 


The point is, MFSK based on FFT is not bad and is very efficient compared 

to the matched correlator approach. It is also potentially upgradable in 
real-time to OFDM. The crucial issues for the MFSK DSP system are: aliasing 
and roundoff noise caused by demodulation to I/Q and decimation, FFT dynamic 
range and tuning control. 


The idea of trying the correlators at signalling frequencies, was to get rid 
of the need for heavy decimation and quadrature demodulation ahead of the FFT, 
considerably simplifying the processing and hopefully reducing aliasing noise. 
So far, no advantage in doing this has been observed. Maybe I should try 
substituting the FFT for a bank of floating point matched correlator detectors 
which would offer more dynamic range compared to the CBFP FFT. 


Perhaps we can try Pawel's suggestions of windowing and extended 
FFT resolution for MFSK systems thus departing from traditional MFSK processing 
to viewing MFSK as a pure spectral analysis problem. 


Regards 

Adrian G4ZHZ 

From JALOCHA@chopin.ifj.edu.pl Tue Apr 11 04:34:20 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA31528 for 
<hfsig@tapr.org>; Tue, 11 Apr 1995 04:34:13 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA20858 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Tue, 11 Apr 1995 11:31:40 +0200 

Date: Tue, 11 Apr 1995 11:33 GMT+1 

Subject: Re: [HFSIG:360] Re: Proposal for a picollo-type modulation scheme 
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <889902D900A0869A@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>With 32 carriers and 4DQPSK on each of them you would have 4000bps. 


This was exactly the number I got fascinated with. 

When it came to the actuall implementation, I found out I have to space 
carriers a bit wider to reduce crosstalk between them so I came down to 
3000 bps. Then, the DQPSK did not work... only DBPSK did (but now I have 
an idea why and I will come back to QPSK) so I came down to 1500 bps 

- still not too bad. 

Timo and Joni from Finland did some tests of this modem and actuall 
performance was real bad. I suspect the tuning is a serious issue here. 
Their signal levels were S3..5 at the distance of about 15 km. 


>Of course the S/N would degrade the performance of such a modulation scheme, 
>I think you can win back a lot with coding. But to occupy a whole SSB 
>channel for 375bps uncoded data is too inefficient. 


The argument to support such inefficiancy is that you can tolerate 
interference from other users whose signals come into your band. 


>The next problem is the robustness of such a system. I believe if one or 
>more frequency bins fade out because of frequency selective fading you are 
>in trouble. You would at least have to do some kind of interleaving to 
>overcome these effects. 


This issue was discussed here last week and we count on our forward 
error correction code to restore symbols missed due to selective 
fading or narrowbanded interferences. 


>The third possibility is the application of broadband signals, OCDM 

>(= orthogonal code division multiplex). I've read through an interesting 
>article on this topic recently (J. Lindner, "Channel Coding and Modulation 
>for Transmission over Multipath Channels", to be published in 

>no. 3 AEUe, May 1995). 


Would be very nice if you could say something more on the ideas 
expressed in this article. 


Yesterday I have made up a band equalization and a ramp-hunting code 

as I described it yesterday (no precise ramp measurement yet, 

just the coincidence of ramp-up with ramp-down). 

I wanted to see how reliable the detection is in the presence of wideband 
and narrowbanded noise. I found my ears are just a bit better :-) 

but basically the sync. could still be detected when I could hardly hear it. 
I should make some more solid signal/noise measurements... 


Pawel 
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X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Adrian wrote: 


>My opinion is that MFSK is the optimum choice for single HF channel working, 
>low-speed data. OFDM is for higher speed working. Both systems need to be 
>developed. Perhaps OFDM could be made to degenerate gracefully towards MFSK 
>in worsening channel conditions. If we think of OFDM as a number of 
>multiplexed MFSK channels, then these channels could be made to drop out 
>so that the same transmitter power becomes concentrated across a smaller 
>bandwidth thus gaining SNR. 


I agree: "both systems need to be developed". 
>The point is, MFSK based on FFT is not bad and is very efficient compared 


>to the matched correlator approach. It is also potentially upgradable in 
>real-time to OFDM. The crucial issues for the MFSK DSP system are: aliasing 


>and roundoff noise caused by demodulation to I/Q and decimation, FFT dynamic 
>range and tuning control. 


My view on the dynamic range of the FFT: 


If I do a 256 point FFT, I scale my input data by 1/256 to avoid potential 
overflow problem (FFT output gets real messy, when overflows come into 
action !). I work with 24-bit numbers (my DSP is DSP56001). 


>From the CODEC I am receiving 16 bit samples which are placed in the higher 
part of the word (bits 8-23). Thus, by dividing by 256 I do not loose any bit 
Infact, I can divide only by 128 if I use the sin(x)2 window 

so I get 1 bit margin. 


Now, I do the actuall FFT. I do not know what exactly happens here 
but from the simulations I could see that an error is introduced 
sometimes on the lowest bit. Thus I almost keep the original 
dynamic range, right ? 


Well, now you may say that with passband+decimation process you _gain_ 
extra dynamic range ? This might be true, but I ask a question: 

are you sure your passband filters do have enough out-of-band rejection 
so that this extra dynamic range it "real" ? 


Apropos finding the highest power: 


On the FFT output I get 24-bit Is and Qs. I compute power as Ix1I+Qx*Q 
and I get a 48-bit number (well, maybe a 49-bit ?). 
I then do 48-bit comparisons to find the peak. 


By the way a question about HF coherence. 

If we do not expect any coherence from HF how can we expect that a piece 
of pure wave (picollo symbol) will stay pure (or coherent in other words). 
If I assume that the incoming signal's phase is random, such piece of pure 
wave should dissolve and its spectrum become wider. 

I suspect the phase isn't changing purely randomly and the changes 

are "coherent" to a certain degree. 

The question is how "coherent" they are, how much can a pure tone 

dissolve on HF ? 


Pawel 
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Date: Tue, 11 Apr 1995 15:13:37 +0100 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:364] Re: Proposal for a picollo-type modulation 
Cc: nash@camail.ca.nmp.nokia.com 


Pawel: 


>If I do a 256 point FFT, I scale my input data by 1/256 to avoid potential 
>overflow problem (FFT output gets real messy, when overflows come into 
>action !). I work with 24-bit numbers (my DSP is DSP56001) . 


>From the CODEC I am receiving 16 bit samples which are placed in the higher 
>part of the word (bits 8-23). Thus, by dividing by 256 I do not loose any bit 
>Infact, I can divide only by 128 if I use the sin(x)‘%2 window 

>so I get 1 bit margin. 


Well there is the advantage in using a 24 bit fixed point processor! 


Pawel, the way I perform FFTs on the ADSP2101 which is only 16 bits :-(, 

is to monitor the exponent of the stage results in block floating point mode, 
and to re-scale the block if the bit growth is 2 bits or more, that is, I 
start with a 2 bit margin. If bit growth occurs, I change the block exponent 
by 2 and re-scale the entire block by this new exponent. In this way I don't 
loose the precision of the input data by scaling by 1/N. 


It is possible that the limiting effect of block floating point can cause 
problems. If, an incorrect frequency bin has a high magnitude which is close 
but just less than the correct frequency bin for the tone being received, 
noise in the incorrect bin could just push the block exponent up by 

one which will cause the whole block to be renormalized. Also, this noise 
will usually have a phase component. Since the real and imaginary data 

are in the same block, there is crosstalk between I/Q in terms of the block 
exponent. This effect worsens the probablility of error at low SNRs. 
Typically I get a character error rate (NB 1 character consists of two symbols) of 
1E-02 at an SNR of -9dB in a AWGN channel. This is about 3dB worse than 

the equivalent analogue MFSK modem (eg LA1117). Some of this could be due to 
aliasing noise though. 


Pawel: 


>Well, now you may say that with passband+decimation process you _gain_ 
>extra dynamic range ? This might be true, but I ask a question: 

>are you sure your passband filters do have enough out-of-band rejection 
>so that this extra dynamic range it "real" ? 


There are trade-offs between simplified decimation and heavy demodulation 
and decimation but with zero-IF FFT-type spectral analysis instead of 
quadrature matched correlators (DFT). I have found in my current MFSK 
modem which uses demodulation in phase quadrature to shift the passband 
down to OHz plus multiple-stage decimation, there is significant aliasing 
which needs sorting out. Most of this aliasing is caused by the 2wo image 


generated by the demodulation process aliasing. Improved input filtering 
would cure this. 


The matched correlator approach has just one decimation stage from 

7680Hz to 2560Hz. This means there is less filtering so less roundoff 
noise and no demodulation which means no 2wo aliasing or further roundoff 
noise. In tests, I have not observed any significant noise due to out of 
band signals aliasing. This coupled with full floating point arithmetic 
for post-accumulation should improve the dynamic range and indeed does 
for one correlator tested in isolation. I think therefore, my way of 
selecting the peak and synchronisation epoch is wrong rather than the 
detector itself. The correlator seems to offer spurious free dynamic range 
of an acceptable range (not sure how many dBs but it works OK in the 
presence of very much stronger out-of-band signals.) 


Pawel: 


>By the way a question about HF coherence. 

>If we do not expect any coherence from HF how can we expect that a piece 
>of pure wave (picollo symbol) will stay pure (or coherent in other words). 
>If I assume that the incoming signal's phase is random, such piece of pure 
>wave should dissolve and its spectrum become wider. 

>I suspect the phase isn't changing purely randomly and the changes 

>are "coherent" to a certain degree. 

>The question is how "coherent" they are, how much can a pure tone 
>dissolve on HF ? 


MFSK is non-coherent on HF so I use non-coherent detection. The FFT 

or matched quadrature correlator detector both work with complex numbers. 
(NB this is another reason why I demodulate the passband to OHz in the 
complex plane - I use a 16 point complex FFT so all 16 points convey 

unique information) Taking the magintude squared just as you do is 

phase independant so no problem with the input signal phase shifting around. 


I think it is good that we are discussing in more detail the implementation 

issues of these digital modems for HF. After all, for an HF channel, things 

like dynamic range are very important and we want to develop top-performance 
demodulators rather than hoping that the channel coding will make up 

for the deficit. 


Regards 

Adrian 

From JALOCHA@chopin.ifj.edu.pl Tue Apr 11 10:12:24 1995 
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Message-id: <B7B3D14A80A07E48@chopin.ifj.edu.pl> 
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Adrian: 
>Well there is the advantage in using a 24 bit fixed point processor! 
I see... your DSP is only 16-bits. 


Are you applying any window to your data before the FFT ? 
Lack of windowing is a good reason for nearby carriers leaking 
into the "good" ones. 


Adrian: 


>Taking the magintude squared just as you do is 
>phase independant so no problem with the input signal phase shifting around. 


I was actually wondering, that if you take a pure tone and start shifting 

its phase around, the tone will no longer stay pure. If the shift rate 

is constant the tone stays pure but changes its frequency (so it may fall 
into another picollo demodulator bin). If the shift rate (or the shift itself) 
is random the tone will dissolve into a set of frequencies spread around 

the original one. If the phase shift is purely random in time, the tone 

gets spread all around the band. 


My (bad) intention was to trigger a discussion on the coherence on the HF. 
People argue that you can not use phase modulation on HF because of lack 
of coherence, but if you do not have any coherence then your signals 

get spread into an infinite band so even CW doesn't get through :-) 


I guess there is still some coherence left on HF :-) and I would like to know 
how much of it is left. How can this missed coherence influence non-coherent 
systems ? For example is it worth to send picollo with 5 Hz spacing between 
tones or would the HF spread such tones over more than 10 Hz so detection 
isn't really possible ? 


Pawel 

From paulr@hagar.udc.neweast.ca Tue Apr 11 10:55:00 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id KAA00458 for 

<hfsig@tapr.org>; Tue, 11 Apr 1995 10:54:55 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA11199; Tue, 11 Apr 95 15:54:50 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA797631894; Tue, 11 Apr 95 13:23:06 nst 

Date: Tue, 11 Apr 95 13:23:06 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 39 Text 

Message-Id: <9503117976.AA797631894@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:366] Re: Proposal for a picollo-type modulation 


Pawel: 


I suspect that the absolute error in tuning your radio will be far greater 
than the offset in a tone during a symbol due to phase errors. By spec on 
the commercial equipment I use, the Radios are supposed to be within +-20Hz 
(older equipment) or +-10Hz(Newer equipment, within last 3-5 years). So if 
one end is +toff, the other is -off, a total of +-40Hz(older) or 
+-20Hz(newer) may be observed. I believe the marine standards for GMDSS 
equipment require the modems to work with upto a 40Hz difference between 
ends, and the radios(new) to have less than a 10Hz error. 


Also, although you probably know this, but anyway... 


Careful of the definition of Coherent detection. You cannot use true PSK on 
HF, but you can use DPSK. i.e. you do not have a reference phase, so PSK is 
not possible. But if you use the previous symbol as a reference, then you 
can use Differential PSK (DPSK). 


I suspect some confuse the limit on using coherent detection with not being 
able to use any form of phase modulation. Thus leading to the arguments 
you've heard. 


In HF the Phase delay can change over time, typically considered to be only 
a small amount during one or two 100baud symbols. So the phase error 
between successive symbols is small. Of course if a symbol phase is in 
error (phase demodulated wrong) then the next symbol may also be 
demodulated wrong since it is relative to it. So often (usually?) errors 
occur in pairs. Maybe this should be considered in the design of error 
correction and interleaving code for such a modem? 


Over longer periods of time phase drift/error on the HF channel becomes 
great (>90degrees after N symbols, N > 10 guess?). So if you locked a phase 
reference at the beginning of the packet and tried PSK demodulation, it 
would probably be well off by the end of the packet. 


just my 2cents worth 
Paul Russell 


From JALOCHA@chopin.ifj.edu.pl Tue Apr 11 11:13:55 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAAQQ591 for 
<hfsig@tapr.org>; Tue, 11 Apr 1995 11:13:48 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id SAA26119 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Tue, 11 Apr 1995 18:10:38 +0200 

Date: Tue, 11 Apr 1995 18:12 GMT+1 

Subject: Re: [HFSIG:367] Re: Proposal for a picollo-type modulation 
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <CO546E9080A07E48@chopin.ifj.edu.pl> 


X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Thanks Paul, very informative answer and it all clear to me: 
the phase is random but it drifts slowly thus one can expect 
coherence over short periods of time and this is a good reason 
for differential phase modulating techniques to work. 


Pawel 
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Tue Apr 11 11:19:59 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAAO0578 for 
<hfsig@tapr.org>; Tue, 11 Apr 1995 11:11:25 -0500 
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th- 
darmstadt.de with SMTP id AA13595 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Tue, 11 Apr 1995 17:23:28 +0200 
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus 
(8.6.9/8.6.9-HRZ) with ESMTP id RAA20770 for <hfsig@tapr.org>; Tue, 11 Apr 1995 
17:23:27 +0200 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id RAA13918 for 
hfsig@tapr.org; Tue, 11 Apr 1995 17:19:16 +0200 
Message-Id: <199504111519.RAA13918@hades> 
Subject: Re: Proposal for a picollo-type modulation 
To: hfsig@tapr.org 
Date: Tue, 11 Apr 1995 17:19:16 +0200 (MESZ) 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 4692 


>>With 32 carriers and 4DQPSK on each of them you would have 4000bps. 


>This was exactly the number I got fascinated with. 

>When it came to the actuall implementation, I found out I have to space 
>carriers a bit wider to reduce crosstalk between them so I came down to 
>3000 bps. Then, the DQPSK did not work... only DBPSK did (but now I have 
>an idea why and I will come back to QPSK) so I came down to 1500 bps 

>- still not too bad. 

>Timo and Joni from Finland did some tests of this modem and actuall 
>performance was real bad. I suspect the tuning is a serious issue here. 
>Their signal levels were S3..5 at the distance of about 15 km. 


Yes, tunig is the main problem. But I still think that DQPSK can be used. 

If you not only use the last received symbol but also the one before that 

you can win back a lot compared to coherent demodulation of QPSK. Furthermore 
with 2 times differential modulation you get rid of the tunig problem. 

On the other hand, you loose about 3dB in S/N for the same BER. This is 

of course too much. I recently came accross an interesting paper which 

covers a new demodulation scheme (M.K.Simon and D.Divsalar, 

"On the Implementation and Performance of Single and Double Differential 


Detection Schemes", IEEE Trans. Comm. COM-40, 1992, p. 278-291 

and F. Edbauer, "Bit Error Rate of Binary and Quaternary DPSK Signals 

with Multiple Differential Feedback Detection", IEEE Trans. Comm. COM-40, 1992, 
p. 457-460). 


>>The third possibility is the application of broadband signals, OCDM 

>>(= orthogonal code division multiplex). I've read through an interesting 
>>article on this topic recently (J. Lindner, "Channel Coding and Modulation 
>>for Transmission over Multipath Channels", to be published in 

>>no. 3 AEUe, May 1995). 


>Would be very nice if you could say something more on the ideas 
>expressed in this article. 


The basic idea behind the article is the generalization of linear block 
modulation with orthogonal functions. If you use single or multicarrier 
transmission - that is you use orthogonal sine waves - you have OFDM. 
If you use other types of orthogonal functions - you have OCDM. 


The author begins with an overview over existing modulation schemes. 

The multicarrier approach is quite old and was taken to reduce 

the complexity of the receiver. As no equalizition is needed, simple 

receiver structures are feasable. It is important to mention that 

single carrier schemes have proven to be more effective, but - of course - 
require very complex demodulators. I like to mention the new Rhode&Schwarz 

HF modem GM857 which uses coded 8PSK on a single carrier to achieve 2k4bps in 
an SSB channel. Multicarrier schemes are effective, if you use advanced 
coding. The rest of the paper is about the relation of channel coding 

and modulation with respect to the multipath channel. 


>From previous work it is clear that you can approach the available 
channel capacity with OFDM by using a method called "water pouring scheme" 
provided you know exactly the channel capacity of each "subchannel". This 
can be done using a back channel from the receiver to the transmitter. 

I think, this can also be done using ARQ techniques. 


The reset of the paper is about what you can to do achieve the maximum 
channel capacity if you do not have his knowledge. For OFDM the simplest 
approach is signal interleaving, you swap the mapping of symbols and 

sub channels. Assuming Rayleigh fading channels, the thus created 
virtual sub channels are also Rayleigh fading. 


If you distribute the symbols over more than one sub channel of the OFDM, you 
get OCDM. He shows that the output of the decoder on the receiver side is now 
not fading at the expense of intersymbol interference between different signals. 


>From a practical point of view this is quite clear, as broadband signals don't 
suffer that much from frequency selective fading than narrow band signals do. 


The main problem is the need for maximum likelihood reception due to the 
intersymbol interference and thus a very complex receiver. 


Alexander 


Alexander F. Kurpiers 

Institut fuer Uebertragungstechnik 

Merckstrasse 25 

D-64283 Darmstadt (Germany) 

Voice: +49-6151-162369 

Fax : +49-6151-165545 

EMail: kurpiers@zeus.uet.e-technik.th-darmstadt.de 
Hamradio: dl8aau@dbO0kg.#nds.deu.eu 


From k5yfw@sacdm10.kelly.af.mil Tue Apr 11 12:07:42 1995 
Received: from sacdm1i0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA01092 for 
<hfsig@tapr.org>; Tue, 11 Apr 1995 12:07:38 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOryjNj-Q002BUC; Tue, 11 Apr 95 12:05 CDT 
Message-Id: <mOryjNj-Q002BUC@sacdm10.kelly.af.mil> 
Date: Tue, 11 Apr 95 12:05:39 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Two Types of Modems 
To: hfsig@tapr.org 


For those of us listening in on the SIG who are non-technical types, I 
gather that there are two types of modems being discussed here. 


One is a very robust modem for worst-case conditions with a low bit 
rate but to ensure thurput...less than 100 BPS 


The second is a high-speed modem, somewhat robust and desired to 
operate under average to poor conditions...about 2400 BPS. 


Additionally, I am assuming that development is designed to fit on 
multiple platforms to include generic soundcards and external DSP 
devices such as the TAPR DSP device. 


Someone may want to re-define/state the efforts here so new 
subscribers can know our direction. 


On a personal note, I believe the greatest interest of this project by 
the amateur radio community will be the ability of the average ham to 

use a simple computer soundcard to send and receive data on HF at data 
rates of up to 2400 BPS over average to poor paths. 


Keep up the fine effort. 


Best Regards, 


qwWalt/K5YFW 
From FORRERJ@frl.orst.edu Tue Apr 11 15:42:18 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAAQ2055 for 
<HFSIG@tapr.org>; Tue, 11 Apr 1995 15:42:15 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id FAAQ2412 for <HFSIG@tapr.org>; Tue, 11 Apr 1995 
05:42:12 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 11 Apr 95 13:47:59 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 11 Apr 95 13:47:48 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 11 Apr 1995 13:47:45 PST8PDT 
Subject: PDM-2 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <735F1242AA4@fr1.orst.edu> 
Alexander, 

Thanks for the Simon & Divsalar reference. 
I learned something new today. 


For those interested - DPSK derives signaling states from the difference in 
phase between successive symbols. If only adjacent symbols are considered, 
this is also called PDM-1, however, if one take the difference spread out 
over 'm' several preceeding symbols, this is called PDM-m: PDM-2 when the 
past two symbols are used - this is also called the second deriative of the 
phase difference. The neat thing about this scheme is that doppler shift 

on the signal is cancelled in the detection process! It is stated that PDM- 
2, when no frequency offset is present, is some 3 - 4 dB worse than PDM- 

1 (i.e. regular DPSK), however, the latter suffers severely in off- 
frequency situations when PDM-2 still performs reasonably. Perhaps a good 
method for tuning or symbol synch? 


PDM-m can be implemented using either the autocorrelation method (i.e. 
correlating the signal with itself one symbol time delayed) or by the I/Q 
method (shift to baseband, integrate/dump, and autocorrelation) . 


I could not make much sense from the Edbauer paper - perhaps Alexander 
could fill us in. In the same volume (COM-40), April issue, by Casas 
and Leung, there also is a paper on the topic of the effects of fading 
on OFDM - sounds somewhat familiar? 


73's 


Johan Forrer, KC7WW 


From Glen_Worstell@notes.seagate.com Tue Apr 11 18:09:44 1995 
Received: from worldcom.com (worldcom.com [198.64.193.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id SAAQ2840 for 
<hfsig@tapr.org>; Tue, 11 Apr 1995 18:09:36 -0500 
Received: from worldcom-18.worldcom.com (worldcom-18.worldcom.com [198.64.193.9]) 
by worldcom.com (8.6.11/8.6.9) with SMTP id QAA17139 for <hfsig@tapr.org>; Tue, 11 
Apr 1995 16:41:45 -0500 
Received: by worldcom-18.worldcom.com (IBM OS/2 SENDMAIL VERSION 1.3.13/3.3) 
id AA5856; Tue, 11 Apr 95 16:34:39 -0700 
Message-Id: <9504112334.AA5856@worldcom-18.worldcom. com> 
Received: from worldcom with "Lotus Notes Mail Gateway for SMTP" id 
FF4AEC2BB319BDC18625619B00767122; Tue, 11 Apr 95 16:34:39 
To: hfsig <hfsig@tapr.org> 
From: Glen Worstell <Glen_Worstell@notes.seagate.com> 
Date: 11 Apr 95 13:15:31 EDT 
Subject: computer noise 
Mime-Version: 1.0 
Content-Type: Text/Plain 


Hi, 

I am interested in experimenting with some of the ideas presented 
in this forum. To that end I connected my clone 486-33 pc to my 
Icom 735 and PK232. The noise level was about 20 over. 

Even using my two meter handheld the noise is stronger than 

many signals. 


I'd like to purchase a new low noise PC. The computer droids 
know less than nothing about RFI. Does anyone have any 
suggestions or experience with particular brands/models? 

Is monitor noise also an issue? 


TIA, 

Glen, KGOT 

From k5yfw@sat.n5lyt.ampr.org Tue Apr 11 18:57:07 1995 

Received: from k5yfw.ampr.org (k5yfw.ampr.org [44.76.2.88]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id SAAQ3045 for 
<hfsig@tapr.org>; Tue, 11 Apr 1995 18:56:53 -0500 

Date: Tue, 11 Apr 95 18:48:08 CST 

Message-Id: <2738@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:369] Re: Proposal for a picollo-type modulation 
In-Reply-To: Your message of Tue, 11 Apr 1995 11:27:18 -0500 
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


Alexander, et al. 


In message <199504111519.RAA13918@hades> Alexander writes: 


The author begins with an overview over existing modulation schemes. 

The multicarrier approach is quite old and was taken to reduce 

the complexity of the receiver. As no equalizition is needed, simple 

receiver structures are feasable. It is important to mention that 

single carrier schemes have proven to be more effective, but - of course - 
require very complex demodulators. I like to mention the new Rhode&Schwarz 

HF modem GM857 which uses coded 8PSK on a single carrier to achieve 2k4bps in 
an SSB channel. Multicarrier schemes are effective, if you use advanced 
coding. The rest of the paper is about the relation of channel coding 

and modulation with respect to the multipath channel. 


VVVV VV VV VV VV 


Could this be something like the single tone modem referenced in 
MIL-STD-188-110a, change notice 2? One tone that can "do" 4800 
BPS without FEC and 2400 BPS with FEC (Reed-Solomon coding) . 


The single tone modem signal sounds just like 3 KHz of noise... 
it fits into a SSB bandpass filter on most U.S. Military 
transceivers. 


Walt 
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Wed Apr 12 01:34:07 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id BAA05427 for 
<hfsig@tapr.org>; Wed, 12 Apr 1995 01:34:03 -0500 
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th- 
darmstadt.de with SMTP id AA17505 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 12 Apr 1995 08:33:17 +0200 
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus 
(8.6.9/8.6.9-HRZ) with ESMTP id IAA17322 for <hfsig@tapr.org>; Wed, 12 Apr 1995 
08:33:17 +0200 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id IAA14075 for 
hfsig@tapr.org; Wed, 12 Apr 1995 08:29:04 +0200 
Message-Id: <199504120629.IAA14075@hades> 
Subject: Re: Proposal for a picollo-type modulation 
To: hfsig@tapr.org 
Date: Wed, 12 Apr 1995 08:29:04 +0200 (MESZ) 
In-Reply-To: <2738@k5yfw.ampr.org> from "Walter D. DuBose - K5YFW" at Apr 11, 95 
07:07:03 pm 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 501 


> 
> Could this be something like the single tone modem referenced in 


MIL-STD-188-110a, change notice 2? One tone that can "do" 4800 
BPS without FEC and 2400 BPS with FEC (Reed-Solomon coding) . 


The single tone modem signal sounds just like 3 KHz of noise... 
it fits into a SSB bandpass filter on most U.S. Military 


transceivers. 


Walt 


VV VV VV VV V 


I just looked in the description of the modem. You are right it's 
MIL-STD-188-110a. 


Alexander 

From nash@camail.ca.nmp.nokia.com Wed Apr 12 03:19:36 1995 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id DAAQ5664 for 

<hfsig@tapr.org>; Wed, 12 Apr 1995 03:19:32 -@500 

Received: from mgw.nmp.nokia.com (mgw.nmp.nokia.com [131.228.233.85]) by 

noknic.nokia.com (8.6.9/8.6.9) with SMTP id LAAQ2187 for <hfsig@tapr.org>; Wed, 12 

Apr 1995 11:19:16 +0300 

Message-Id: <199504120819.LAAQ2187@noknic.nokia.com> 

Received: from camail.ca.nmp.nokia.com by mgw.nmp.nokia.com with SMTP 
(1.38.193.4/16.2) id AA19129; Wed, 12 Apr 1995 10:15:46 +0200 

Received: from bashful.ca.nmp.nokia.com (bashful) by camail with SMTP 
(1.37.109.14/16.2) id AA298134709; Wed, 12 Apr 1995 09:18:29 +0100 

Date: Wed, 12 Apr 1995 09:18:29 +0100 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:366] Re: Proposal for a picollo-type modulation 


Pawel: 


>Are you applying any window to your data before the FFT ? 
>Lack of windowing is a good reason for nearby carriers leaking 
>into the "good" ones. 


My modem deliberatly uses no window. The sidelobe information is used in two 
ways: 

a) by taking the ratio of power in all FFT bins to that in the current 
peak bin, we get a useful "confidence estimate" which is used for 
recovering synchronisation but can also be used as a soft decision 
for a Viterbi Algorithm. 


b) More specifically: I have an auto-tuning algorithm which I have 
tested using MathCad but currently is not in the modem. This 
algorithm uses the adjacent frequency bins to the peak to compute 
with a high degree of confidence and accuracy (so far as the 
simulations have shown) the frequency tuning error. This can be 
used to track drift and Doppler shift as well as perform fine 
tuning after a user has coarse-tuned the signal. The same algorithm 


can be made to track phase changes (possibly as quick as those you 
mention below) by using the FFT phase information. Perhaps this 
algorithm could be combined with your "triangular" course tuning 
system to enable the modem to automatically acquire then track 

the signal. I feel auto-tuning is a very important issue which is 
essential for amateur high-performance digital modems given the 
range of amateur HF equipment available. 


All the bins are in effect matched filters, one for each tone with no 
redundancy. 


Pawel: 


>I was actually wondering, that if you take a pure tone and start shifting 
>its phase around, the tone will no longer stay pure. If the shift rate 

>is constant the tone stays pure but changes its frequency (so it may fall 
>into another picollo demodulator bin). If the shift rate (or the shift itself) 
>is random the tone will dissolve into a set of frequencies spread around 

>the original one. If the phase shift is purely random in time, the tone 

>gets spread all around the band. 


This reminds me of some work I did investigating the effects of fast fading 
on MFSK. MFSK is a bit prone to fast fades (eg fade rate >1Hz.) The effect 
is that the tone's energy is spread across a band with a normal (Gaussian) 
distribution due to the violent (eg 180degs) phase changes that occur with 
this type of fade. The width of the modulation depends upon the fade rate. 
In the case of orthogonal MFSK, the effect of the 180 degree phase change is 
to create a strong component in the adjacent frequency bins which when 
integrated can produce an erroneous selection. 


This is where perhaps I need to look at the demodulation of MFSK as a pure 
spectral analysis problem rather than the slightly "digital for analogue" 

way in which the current modem works. Finer FFT resolution with windowing 

as you suggest would reduce cross-talk. 


Pawel: 


>I guess there is still some coherence left on HF :-) and I would like to know 
>how much of it is left. How can this missed coherence influence non-coherent 
>systems ? For example is it worth to send picollo with 5 Hz spacing between 
>tones or would the HF spread such tones over more than 10 Hz so detection 
>isn't really possible ? 


Doppler shifts of 5Hz have been observed on HF circuits therefore I assume that 
this narrow spacing would cause problems. Also, the narrower the separation 

the more prone the MFSK system becomes to selective fading. If the frequency 
separation of two tones is made equal to the reciprocal of the differential 
path delay, one tone will be at a maximum when the other is at a minimum. 
Therefore, a typical MFSK signal with a bandwidth between 180Hz and 360Hz 
(single channel) affords some protection against multipath selective fading. 
Infact, this is apparently where MFSK scores highly over straight DPSK - it 

is much better in a selective fading channel. However, I think this is not 

the issue it was with the advent of sophisticated channel coding techniques 


available. 


Regards 
Adrian 


From JALOCHA@chopin.ifj.edu.pl Wed Apr 12 04:35:20 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAAQ5798 for 
<hfsig@tapr.org>; Wed, 12 Apr 1995 04:35:10 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA@OQ826 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 12 Apr 1995 11:32:45 +0200 

Date: Wed, 12 Apr 1995 11:34 GMT+1 

Subject: Re: [HFSIG:367] Re: Proposal for a picollo-type modulation 
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <51E7C25BO0A092DA@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Paul: 


>In HF the Phase delay can change over time, typically considered to be only 
>a small amount during one or two 100baud symbols. So the phase error 
>between successive symbols is small. 


A related question: what about the group delay variation across frequency ? 

I mean when I am receiving a multi-carrier signal and I find the symbol timing 
for one carrier can I use same timing for other carriers ? 

Or should I adjust the symbol timing for every carrier separately ? 


By the way, does an average SSB filter introduces a significant 
group delay variation ? If we use 100 bps per carrier then variation 
of +/- few ms is very significant. 


Pawel 

From paulr@hagar.udc.neweast.ca Wed Apr 12 07:14:11 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAAQ6140 for 

<hfsig@tapr.org>; Wed, 12 Apr 1995 07:14:07 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA14062; Wed, 12 Apr 95 12:14:05 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA797705048; Wed, 12 Apr 95 09:41:43 nst 

Date: Wed, 12 Apr 95 09:41:43 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 36 Text 

Message-Id: <9503127977 .AA797705048@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:372] computer noise 


I have found files (inc FAQs) that mention cures for RFI at: 
mailing list: 


send message containing word "index" in body to info@arrl.org 


try also: 
ftp://ftp.cs.buffalo.edu/pub/ham-radio/ 
http: //dingus.n5lyt.datapoint.com:80/tapr/ 
http: //hamster.business.uwo.ca/ 


If anyone out there can tell me where to get QEX, QST and the other publications 
often referred to on this list I would appreciate it. 


Paul Russell 


bead rte ares seen ek ee Reply Separator 
Subject: [HFSIG:372] computer noise 

Author: hfsig@tapr.org at nwtsmtp 

Date: 4/11/95 8:42 PM 


Hi, 

I am interested in experimenting with some of the ideas presented 
in this forum. To that end I connected my clone 486-33 pc to my 
Icom 735 and PK232. The noise level was about 20 over. 

Even using my two meter handheld the noise is stronger than 

many signals. 


I'd like to purchase a new low noise PC. The computer droids 
know less than nothing about RFI. Does anyone have any 
suggestions or experience with particular brands/models? 

Is monitor noise also an issue? 


TIA, 
Glen, KGOT 


From paulr@hagar.udc.neweast.ca Wed Apr 12 07:41:19 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAAQ6284 for 

<hfsig@tapr.org>; Wed, 12 Apr 1995 07:41:08 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA14102; Wed, 12 Apr 95 12:41:05 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA797706668; Wed, 12 Apr 95 10:10:16 nst 

Date: Wed, 12 Apr 95 10:10:16 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 59 Text 

Message-Id: <9503127977 .AA797706668@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:376] Re: Proposal for a picollo-type modulation 


>Paul wrote: 
>>In HF the Phase delay can change over time, typically considered to be 
>>only a small amount during one or two 100baud symbols. So the phase error 


>>between successive symbols is small. 

> 

>Pawel wrote: 

>A related question: what about the group delay variation across frequency ? 
>I mean when I am receiving a multi-carrier signal and I find the symbol timing 
>for one carrier can I use same timing for other carriers ? 

>Or should I adjust the symbol timing for every carrier separately ? 

> 

>By the way, does an average SSB filter introduces a significant 

>group delay variation ? If we use 100 bps per carrier then 

>variation of +/- few ms is very significant. 


Hadn't thought about it this way, I hope its not significant. I've been allowing 
the windowing effect to cure/hide any variance in delay between frequencies. 
i.e. the symbols were pinched near their edges, so several samples of variance 
would have little effect at the edges. But if I'm going to be shaping over 
several symbols as you have suggested, I don't know anymore?! 


Definitely the phase of each tone in a symbol (M-ary DPSK) is compared to the 
same tone in the preceding symbol, not a reference tone, as there may be 
different phase delays per tone (here we are comparing the phase of a single 
cycle of a sine wave, not the time delay of the whole symbol's tone). But if the 
delay differences per tone are such that the difference in propagation of each 
tone affects symbol timing - our modems are going to be significantly more 
complex - basically a bunch of independent DPSK or FSK modems running totally 
independently, different FFT's, DPLL's, etc per tone. 


I have seen no references in anyone's designs for this yet, including what I 
have read about Clover and MIL-STD-188, etc. If the variance in propagation 
delays would affect DPSK, they would also affect FSK. It may not be optimal, but 
since no-one else has found it a problem, I'm going to ignore it till I find it 
a problem. "Ignorance is bliss" - you are trying to steal my "bliss" <g>. 


But then again, alot of these designs use correlators, not FFT's. The 
correlation on each tone "may" track independently from the next and thus 
compensate for this. Whereas an FFT samples all the Tones from the same 
reference time-mark. Hum...? 


The following are only guesses, Someone please provide factual info: 


Maybe someone more knowledgable will step in, but I toss in some idle comments 
here. Speed through a medium of electromagnetic signals is related to the speed 
of light. All of our signals when modulated to RF are relatively the same 
frequency - whats a 1KHz tone difference when modulated onto 5MHz - 5.000 vs 
5.001 - little. So I would expect most of the group phase variance to occur 
while the signal is in the audio spectrum, before and after modulation (or 
during the modulation). I'll hazard a guess that the variance in the signals 
propagation no more than a fraction of a cycles of the audio tone (when in RF 
state). If you have the group delay plots from any of your filter designs handy, 
check them and see what difference is for audio level frequencies. Multiple by 
about 10 for all the stages it passes through - will it affect bit timing? - 
i.e. more than about ~8 audio samples at 8KHz sampling (64 samples/symbol, ~1/8 
symbol, 1 millisecond)? Different shaping/windowing functions will provide 


more/less grace around the edges of a symbols. 
Paul Russell 


From paulr@hagar.udc.neweast.ca Wed Apr 12 09:47:20 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA06671 for 

<hfsig@tapr.org>; Wed, 12 Apr 1995 09:47:12 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA15907; Wed, 12 Apr 95 14:47:05 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA797714228; Wed, 12 Apr 95 12:16:40 nst 

Date: Wed, 12 Apr 95 12:16:40 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 36 Text 

Message-Id: <9503127977 .AA797714228@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:372] computer noise 


I have found files (inc FAQs) that mention cures for RFI at: 
mailing list: 
send message containing word "index" in body to info@arrl.org 


try also: 
ftp://ftp.cs.buffalo.edu/pub/ham-radio/ 
http: //dingus.n5lyt.datapoint.com:80/tapr/ 
http: //hamster.business.uwo.ca/ 


If anyone out there can tell me where to get QEX, QST and the other publications 
often referred to on this list I would appreciate it. 


Paul Russell 


ee ee ee ee ee Reply Separator 
Subject: [HFSIG:372] computer noise 

Author: hfsig@tapr.org at nwtsmtp 

Date: 4/11/95 8:42 PM 


Hi, 

I am interested in experimenting with some of the ideas presented 
in this forum. To that end I connected my clone 486-33 pc to my 
Icom 735 and PK232. The noise level was about 20 over. 

Even using my two meter handheld the noise is stronger than 

many signals. 


I'd like to purchase a new low noise PC. The computer droids 
know less than nothing about RFI. Does anyone have any 
suggestions or experience with particular brands/models? 

Is monitor noise also an issue? 


TIA, 
Glen, KGOT 


From FORRERJ@frl.orst.edu Wed Apr 12 10:55:38 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAAQ7084 for 
<HFSIG@tapr.org>; Wed, 12 Apr 1995 10:55:34 -@500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id AAAO7969 for <HFSIG@tapr.org>; Wed, 12 Apr 1995 
00:55:29 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 12 Apr 95 9:01:18 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 12 Apr 95 9:01:16 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Wed, 12 Apr 1995 09:01:16 PST8PDT 
Subject: ITU/TIES 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <7492B2E7EAF@frl.orst.edu> 
Hi All, 
I need some help finding a CCIR document on ITU/TIES. 


The ITU server is on the WWW at: http:\\www.itu.ch 

though the amount of literature are overwhelming. 

Does anyone know where to look/obtain a specific issue of the 
CCIR specifications ? 


I know Tom McDermott has told us how to do this, though have 
not succeeded myself. I have not been able to contact Tom via 
e-mail lately. Anyone know his whereabouts? 


Any help/pointers would be much appreciated. 
73's 


--Johan, KC7WW 
From rsmith@internetMCI.COM Wed Apr 12 11:31:42 1995 
Received: from mailsrv1.pcy.mci.net ([204.70.138.5]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with ESMTP id LAAQ7228 for <hfsig@tapr.org>; Wed, 12 Apr 1995 
11:31:34 -0500 
Received: from [204.71.164.23] (dialup23.Washington.mci.net) 
by MAILSRV1.PCY.MCI.NET (PMDF V4.3-12 410044) 
id <Q1HP92FB69CW9I5MS20@MAILSRV1.PCY.MCI.NET>; Wed, 
12 Apr 1995 12:30:59 +0000 (GMT) 
Date: Wed, 12 Apr 1995 12:31:21 -0500 
From: Bob Smith <rsmith@internetMCI.COM> 
Subject: computer noise 
To: "hfsig@tapr.org" <hfsig@tapr.org> 


Message-id: <Q1HP92FBPO7695MS20@MAILSRV1.PCY.MCI.NET> 
X-Mailer: E-Mail Connection vb.2.5.02 
Content-transfer-encoding: 7BIT 


-- [ From: Bob Smith * EMC.Ver #b.2.5.02 ] -- 
You may try good grounding techniques Glen. Strap everything with the 


braid from RG/8 then to your station ground. This cleared things up very 
well for me. 


Date: Tuesday, 11-Apr-95 06:10 PM 


From: Glen Worstell \ Internet: 
(glen_worstell@notes.seagate.com) 
To: hfsig@tapr.org \ Internet: (hfsig@tapr. org) 


You may try good grounding techniques Tia. Strap everything with the braid 
from RG/8 then to your station ground. This cleared things up very well 
for me. 


Subject: [HFSIG:372] computer noise 


Hi, 

I am interested in experimenting with some of the ideas presented in this 
forum. To that end I connected my clone 486-33 pc to my Icom 735 and 
PK232. The noise level was about 20 over. Even using my two meter handheld 
the noise is stronger than many signals. 


I'd like to purchase a new low noise PC. The computer droids know less 
than nothing about RFI. Does anyone have any suggestions or experience 
with particular brands/models? Is monitor noise also an issue? 


TIA, 
Glen, KGOT 
Times FORWARD, End of original message ------- 


From mcdermot@eagle.aud.alcatel.com Wed Apr 12 16:19:16 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA09044 for 
<hfsig@tapr.org>; Wed, 12 Apr 1995 16:19:13 -0500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA16347; Wed, 12 Apr 95 16:19:11 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ4448; Wed, 12 Apr 95 16:19:10 CDT 
Date: Wed, 12 Apr 95 16:19:10 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9504122119.AA04448@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:380] ITU/TIES 


> From hfsig@tapr.org Wed Apr 12 11:14:35 1995 
> Reply-To: hfsig@tapr.org 


Originator: hfsig@tapr.org 

Sender: hfsig@tapr.org 

To: hfsig@tapr.org 

Subject: [HFSIG:380] ITU/TIES 

X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas 
X-Comment: Tucson Amateur Packet Radio HF Special Interest Group 
Content-Length: 489 

X-Lines: 18 


Hi All, 

I need some help finding a CCIR document on ITU/TIES. 

The ITU server is on the WWW at: http:\\www.itu.ch 

though the amount of literature are overwhelming. 

Does anyone know where to look/obtain a specific issue of the 
CCIR specifications ? 

I know Tom McDermott has told us how to do this, though have 

not succeeded myself. I have not been able to contact Tom via 
e-mail lately. Anyone know his whereabouts? 

Any help/pointers would be much appreciated. 

73's 


--Johan, KC7WW 


VVVVV VV VV VV VV VV VV VV VV VV VV VV WV 


OK. Here's what I did. 


1. telnet gopher.itu.ch 2000 
This connects you to the gopher at CCITT. 

2. Theres a list of choices. Use J to go down, K to go up (UNIX standard) 
or you can type in the number you want, and it will go there 
directly. 

3. I selected 3 - ITU Standards, Publications, Databases, Meetings, Press... 

4. I selected 2 - ITU Radiocommunications Standards 

5. From the next menu, I selected 23 - Index of ITU-R Recommendations by 
numerical order. 

6. You can then download the raw ASCII or a WORD2.0 version. 


Other paths through the gopher... 

3. Select 1 - ITU Telecommunications Standards. 

4. Select 13 - M series Recommendations - you can look through the list 
of recommendation titles on line, or select the option to 
download a postscript version of the list. 


Another path... 


Select 9 - Catalog of ITU-R Recommendations 
this will show how to search by keyword(s) through the recommendation, 


A search on ‘Propagation’ turned up a number of cited references. 


there are many other search engines available, and some of the text of the 
recommendations, etc. are available on-line by Postscript, ASCII, or 
WORD2.0 download. 


- Tom, N5EG 


2. Select 3. from the main menu - ITU Telecommuncations 


Sere eee cee aie eee eee eee ee ee Eo eer OER PEAT Ren te $m ey at ERO Tren 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
a a ate eer srt ate ee tages ct A ce ee Ne ene hes Rea rae Rees 


From mcdermot@eagle.aud.alcatel.com Wed Apr 12 16:54:01 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA09205 for 
<hfsig@tapr.org>; Wed, 12 Apr 1995 16:53:57 -0500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA17491; Wed, 12 Apr 95 16:53:55 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ4956; Wed, 12 Apr 95 16:53:53 CDT 
Date: Wed, 12 Apr 95 16:53:53 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9504122153 .AA04956@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Gopher screen shots (long) 


Here's some screen shots on the way to finding the 
ITU-R M-series recommendations..... 


ITU Telecom Information Exchange Services (TIES) 
International Telecommunication Union (ITU) 


About ITU, TIES, ITUDOC, Copyright, What's new.../ 

Search menu titles in ITU Gopher <?> 

ITU Standards, Publications, Databases, Meetings, Press.../ 
ITU Telecommunication Standardization Sector/ 

ITU Radiocommunication Sector/ 

ITU Telecommunication Development Sector/ 

ITU General Secretariat/ 


NO OBWDN PR 


8. ITU Office of the Secretary-General/ 

9. TELECOM Exhibitions and Forums/ 

10. Telecommunications-related topics/ 

11. United Nations & international organizations/ 
12. Permanent Missions based in Geneva/ 

13. Other information services/ 


Press ? Help, q Quit, D Download Page: 1/1 
ITU Telecom Information Exchange Services (TIES) 
ITU Standards, Publications, Databases, Meetings, Press... 


ITU Telecommunication Standards (ITU-T Recommendations) / 
ITU Radiocommunication Standards (ITU-R Recommendations) / 
ITU Publications (July 1994 Catalogue) 

ITU Schedule of Meetings/ 

ITU Press Releases/ 

ITU Global Telecom Directory/ 

ITU Country Codes database/ 

Catalogue of ITU-T Recommendations/ 

Catalogue of ITU-R Recommendations/ 

10. Catalogue of ITU-R Questions/ 

11. Database of ITU Software for Frequency Management/ 

12. ITU/BDT Databases/ 

13. ITU Constitution, Convention, .../ 

14. ITU Telecommunication Terminology Database (TERMITE) / 


OMAN DOKRWNHER 


Press ? Help, q Quit, u up a menu, D Download 


Page: 1/1 


ITU Telecom Information Exchange Services (TIES) 


ITU Radiocommunication Standards (ITU-R Recommendations) 


1. Series 


service../ 


2. Series 
recording. 


3. Series 
4. Series 
(televisi. 
5. Series 
6. Series 
com. ./ 

7. Series 
Crew A 


8. Series 
9. Series 
med. ./ 

10. Series 
11. Series 
12. Series 
13. Series 


14. Series 


15. Series 
16. Series 
sta../ 

17. Series 
subject. ./ 


ITU-R 


ITU-R 


./ 


ITU-R 
ITU-R 


.f 


ITU-R 
ITU-R 


ITU-R 


ITU-R 
ITU-R 


ITU-R 
ITU-R 
ITU-R 
ITU-R 


ITU-R 
ITU-R 
ITU-R 


ITU-R 


BO Recommendations 


BR Recommendations 


BS Recommendations 
BT Recommendations 


F Recommendations 
IS Recommendations 


M Recommendations 


PI Recommendations 
PN Recommendations 


RA Recommendations 
S Recommendations 
SA Recommendations 
SF Recommendations 


SM Recommendations 


[Broadcasting satellite 
[Sound and television 


[Broadcasting service (sound) ]/ 
[Broadcasting service 


[Fixed service] / 
[Inter-service sharing and 


[Mobile, radiodetermination, 


[Propagation in ionized media] / 
[Propagation in non-ionized 


[Radioastronomy ] / 

[Fixed satellite service] / 
[Space applications]/ 
[Frequency sharing between the 


[Spectrum management techniques] / 


SNG Recommendations [Satellite news gathering] / 


TF Recommendations 


V Recommendations 


[Time signals and frequency 


[Vocabulary and related 


18. List of ITU-R Recommendations available electronically to TIES 


reg../ 


19. Table of ITU-R Recommendations (1994), Resolutions & Questions 


ava../ 


20. HOW-TO-ORDER ITU-R Recommendations/ 

21. Distribution of Recommendations in force as from 2 September 1994/ 
22. Index of ITU-R Recommendations SERIES/ 

23. Index of ITU-R Recommendations by numerical order/ 

24. 1994 Volumes of ITU-R Recommendations/ 


Press ? Help, q Quit, u up a menu, D Download 


Page: 1/1 


ITU Telecom Information Exchange Services (TIES) 
Index of ITU-R Recommendations SERIES 
--> 1. [ASCII Lang: EFS Bytes: 3492 Updated: 94-01-06 ITU-6701] 


2.  [WINWORD2.0 Lang: EFS Bytes: 7869 Updated: 94-09-06 ITU-669.. 
<Bin> 


Press ? Help, q Quit, u up a menu, D Download Page: 


ITU Telecom Information Exchange Services (TIES) 
List of ITU-R M-Series Recommendations in force 
--> 1. [ASCII Lang: EFS Bytes: 62628 Updated: 94-11-16 ITU-6712] 


2.  [WINWORD2.0 Lang: EFS Bytes: 54375 Updated: 94-11-15 ITU-66.. 
<Bin> 


1/1 


Press ? Help, q Quit, u up a menu, D Download Page: 1/1 


a Pe cy ar Ee a Me ce SA tay cn Rn er States Be rata ey Pere tone tly i 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
WiGeeiGon 2h nots aecche on sete boos GaSe S POL Seco ecces ote tecee of eo 


From erik@ve7mdl.ampr.org Wed Apr 12 21:07:14 1995 
Received: from whistler.sfu.ca (whistler.sfu.ca [142.58.103.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA10690 for 
<hfsig@tapr.org>; Wed, 12 Apr 1995 21:07:09 -0500 
From: erik@ve7mdl.ampr.org 
Received: from hamgate.ve7sfu.ampr.org (hamgate.comm.sfu.ca [142.58.173.14]) by 
whistler.sfu.ca with SMTP (8.6.11/SFU-2.6H) 
id TAAQ2569 for <hfsig@tapr.org> (from erik@ve7mdl.ampr.org); Wed, 12 Apr 1995 
19:07:08 -0700 
Received: from ve7mdl.ampr.org by hamgate.ve7sfu.ampr.org (JNOS1.10i) with SMTP 
id AA3180 ; Wed, 12 Apr 95 17:50:47 
Date: Wed, 12 Apr 95 19:07:06 
Message-Id: <12157@ve7mdl.ampr.org> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:380] ITU/TIES 
In-Reply-To: your message of Wed Apr 12 10:58:05 1995 
<7492B2E7EAF@frl.orst.edu> 


CCIR is now called ITU-R. You can get a list of the documents via email. 


I think the email address is ‘itudoc@itu.ch'. Try putting ‘info' or 
‘index' in the first line of the message. 


If it does not work, try sending me a message at ‘erik@mda.ca' and I will 
dig out the detailed instructions at work. 


73 de VE7MDL .... Erik. 
From mcdermot@eagle.aud.alcatel.com Thu Apr 13 09:02:45 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA14023 for 
<hfsig@tapr.org>; Thu, 13 Apr 1995 09:02:42 -@500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQ8715; Thu, 13 Apr 95 09:02:41 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ5630; Thu, 13 Apr 95 09:02:40 CDT 
Date: Thu, 13 Apr 95 09:02:40 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9504131402 .AA05630@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Optimal OFDM pulses 


I came across an interesting reference: 


"Optimal Finite Duration Pulses for OFDM", A. Vahlin & N. Holte, 
Globecom '94, pg. 258-262, paper #7.7 


It discusses the generation of a pulse that is finite in duration, yet has 
good spectral properties for OFDM systems. Three examples listed look 
pretty good. Unfortunately, there is no closed-form solution to the 
minimization effort. It requires solving 20 simultaneous equations looking 
for optimal coefficients of a spheroidal wave function I've never heard of 
(and 

is not documented in the paper). The author provides the coefficients for 
2T, 3T, and 4T length pulses (where h(t) is zero outside the interval), and 
the very good spectrum for the pulses. However, without the PSWF, 

I cannot numerically regenerate h(t). The article has some references to 
the BSTJ, back about 1960 when this wave function was defined. 


There are some other references in the article pointing to more recent IEEE 
Transactions on Communications addressing the subject, but I don't have the 
article with me. If there is any interest, I'll post the references. 


- Tom, N5EG 
wee eee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee eee ee ee Si 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 


[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 
[ June 23-27, 1996, Dallas, Tx. ] | 


Bee ett ta tou aterat ne set htete ce het ta tate nat tte Ment ne Wc atibeteste dai atlanta beta hota 
From mcdermot@eagle.aud.alcatel.com Thu Apr 13 09:23:50 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA14304 for 
<hfsig@tapr.org>; Thu, 13 Apr 1995 09:23:47 -@500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQ9414; Thu, 13 Apr 95 09:23:45 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ5641; Thu, 13 Apr 95 09:23:44 CDT 
Date: Thu, 13 Apr 95 09:23:44 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9504131423 .AA05641@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:378] Re: Proposal for a picollo-type modulation 


Paul Russell writes: 


> Definitely the phase of each tone in a symbol (M-ary DPSK) is compared to 
the 

> same tone in the preceding symbol, not a reference tone, as there may be 

> different phase delays per tone (here we are comparing the phase of a single 
> cycle of a sine wave, not the time delay of the whole symbol's tone). But if 
the 

> delay differences per tone are such that the difference in propagation of 
each 

> tone affects symbol timing - our modems are going to be significantly more 

> complex - basically a bunch of independent DPSK or FSK modems running 
totally 

> independently, different FFT's, DPLL's, etc per tone. 


Most of the literature on HF channel simulation has shown/assumed 
that the channel is non-dispersive out to 4 khz bandwidth. This means that 
the propagation velocity is not frequency-dependent. This assumption 
breaks down at greater bandwidth. Thus, symbol-timing can generally be 
derived for a group of carriers. However, the symbol duration must be long 
enough that multi-path distortion does not move an individual pulse or 
channel very much with respect to the recovered symbol timing. This 
timing is usually in the range 50-200 baud on many HF circuits. 


- Tom, N5SEG 

aN a a eR te Renae hia at Sie eS ei eet Spe Ne ae pe ee ea ited SpA a eat eee 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
Oe reser nT et on cre Me alate h eth Set Matt ates Lt cae fh ee al tar She neat ea etcatl tO 


From FORRERJ@frl.orst.edu Thu Apr 13 12:37:26 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA16022 for 


<hfsig@tapr.org>; Thu, 13 Apr 1995 12:37:23 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA16438 for <hfsig@tapr.org>; Thu, 13 Apr 1995 
02:37:14 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Thu, 13 Apr 95 10:43:06 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 13 Apr 95 10:42:56 
PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 13 Apr 1995 10:42:53 PST8PDT 
Subject: Re: [HFSIG:382] Re: ITU/TIES 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <762DDAD64A6@frl.orst.edu> 


Greetings, 
Thanks for all the help with ITU/TIES. 
73's 


Johan, KC7WW 
From tomob@netcom.com Fri Apr 14 15:00:09 1995 
Received: from netcom15.netcom.com (netcom15.netcom.com [192.100.81.128]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA22411 for 
<hfsig@tapr.org>; Fri, 14 Apr 1995 15:00:06 -0500 
Received: by netcom15.netcom.com (8.6.12/Netcom) 
id MAAQ2865; Fri, 14 Apr 1995 12:59:56 -0700 
Date: Fri, 14 Apr 1995 12:59:55 -0700 (PDT) 
From: "Thomas E. O'Boyle" <tomob@netcom. com> 
Subject: DSP Developer Needed 
To: HFSIG <hfsig@tapr.org> 
Message-ID: <Pine.3.89.9504141237 .A2107-0100000@netcom15> 
MIME-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Greetings to members of the HFSIG! 


We are a small company (six people) located in Chicago that is working 

to finish development of a commercial HF data product. We have a 

targeted niche application in mind, and have received one patent and another 
is pending. Our design is based on a TMS320 series DSP. We have modeled 

the specific modulation approach that we intend to use against a simulation 
of multi-path and Gaussian noise and believe that we are on the right track. 
We are looking for an additional full-time engineer for this project. 
Qualifications are microcontroller and DSP experience and a love of radio. 
This might be the chance to enhance your career while working on a project 
related to your hobby. Competitive pay and benefits; informal, hardworking, 
entrepreneurial environment. For more info, fax a letter and resume to 


(312) 463-9738, or respond by private E-mail. 
Thanks to Johan Forrer for allowing us to post this message. 


73 de Tom, N9OGUN. 
tomob@netcom.com 


From tomob@netcom.com Fri Apr 14 15:01:12 1995 
Received: from netcom15.netcom.com (netcom15.netcom.com [192.100.81.128]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA22424 for 
<hfsig@tapr.org>; Fri, 14 Apr 1995 15:01:09 -0500 
Received: by netcom15.netcom.com (8.6.12/Netcom) 
id MAAQ2413; Fri, 14 Apr 1995 12:55:12 -0700 
Date: Fri, 14 Apr 1995 12:55:11 -0700 (PDT) 
From: "Thomas E. O'Boyle" <tomob@netcom. com> 
Subject: DSP Developer Needed 
To: HFSIG <hfsig@tapr.org> 
Message-ID: <Pine.3.89.9504141215 .A2107-0100000@netcom15> 
MIME-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


kk 
tomob@netcom.com 


From karn@qualcomm.com Fri Apr 14 15:53:54 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA22759 for 
<hfsig@tapr.org>; Fri, 14 Apr 1995 15:53:50 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id NAA21549; 
Fri, 14 Apr 1995 13:56:45 -0700 

Date: Fri, 14 Apr 1995 13:56:45 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199504142056.NAA21549@servo.qualcomm. com> 

To: hfsig@tapr.org, tcp-group@ucsd.edu 

Subject: my web page 


I've finally gotten around to creating a web page. There's not a lot of 
technical content yet, but I intend to update it with pointers to my 
various papers and software projects. 


The URL is 
http: //www.qualcomm.com/people/pkarn 


--Phil 
From jra@ag9v.ampr.org Sat Apr 15 15:58:40 1995 
Received: from udcps3.cps.udayton.edu (udcps3.cps.udayton.edu [131.238.17.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id PAA29193; Sat, 15 Apr 1995 
15:58:36 -0500 
Received: by udcps3.cps.udayton.edu (Smail3.1.26.7 #8) 
id mOsQEzP-0002XTC; Sat, 15 Apr 95 21:02 GMT 
Received: (from jra@localhost) by ag9v.ampr.org (8.6.9/8.6.9) id OAA05660; Sat, 15 


Apr 1995 14:00:10 -0400 

Message-Id: <199504151800 .0AA05660@ag9v.ampr.org> 
Subject: PACK&\ 

To: aprssig@tapr.org, hfsig@tapr.org, dsp93sig@tapr.org 
Date: Sat, 15 Apr 1995 14:00:09 -0400 (EDT) 

From: jra@ag9v.ampr.org 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1777 


Attending the 1995 Dayton Hamvention? Time's running out to register 
for PACK*BASH! 


What? 


When? 


Where? 


How? 


> 


new event for the digitally-inclined ham, featuring: 
Buffet dinner (with cash bar) 
Dewayne Hendricks, WA8DZP, speaking on PCS, SS, FCC, and 
other acronyms 
Bob Bruninga, WB4APR, speaking on the Future of APRS 
Prize raffle 
TAPR special interest group meetings 
"Birds of a Feather" gatherings 


+ + 


+ + OF 


Friday evening, April 28, 1995 
Dinner starts at 7:00 pm 

Speaker at 7:45 

Meetings to begin after the speaker 


TJ's Restaurant 
2462 Dryden Road, Dayton 
(Dryden Road exit, I75 -- across from the Holiday Inn) 


Dinner requires advance registration and payment BY APRIL 24th, 1995. 
Seating for dinner only is limited, so register early! The cost is 
$16.00 per person, tax and tip included. 


All amateurs are welcomed to attend, enjoy the speaker, and 
particpate in the meetings, although only those purcashing a dinner 


can eat. 


To register, contact: 


PACK*BASH 


c/o TAPR 
8987-309 E. Tanque Verde Road #337 
Tucson, AZ 85749-9399 


Phone: (817) 383-0000 
Fax: (817) 566-2544 
Internet: TAPR@TAPR.ORG 


Visa/Mastercard Accepted 


Who? 
PACK*xBASH is co-sponsored by TAPR -- Tucson Amateur Packet Radio, 
the national leader in digital communication -- and the Miami 
Valley FM Association, Dayton's packet radio club. 


For further information, contact TAPR, or email packbash@ag9v.ampr.org or 
BASH@N8ACV .#DAY.OH.USA.NOAM 
John Ackermann AG9V 
Internet: jra@ag9v.ampr.org 
Packet: AGOV@N8ACV .4EDAY .OH.USA 
From FORRERJ@frl.orst.edu Tue Apr 18 13:16:09 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA16800 for 
<HFSIG@tapr.org>; Tue, 18 Apr 1995 13:16:05 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id DAA14982 for <HFSIG@tapr.org>; Tue, 18 Apr 1995 
03:15:38 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 18 Apr 95 11:21:56 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 18 Apr 95 11:21:40 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 18 Apr 1995 11:21:35 PST8PDT 
Subject: HFSIG activities 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <56CCA54471@fr1l.orst.edu> 
Hi All, 


A brief update: There are considerable amount of activity going on behind 
the scenes - this mostly has to with DSP specific stuff. Adrian, G4ZHZ, 
and Pawel, SP4VRC, both are making good progress. 


One reality that we have to deal with is that different DSP platforms are 
being used - understandable for good reasons. I am trying to stay involved 
by cross-porting where possible. For this reason, I have been working at 
porting some of the Finnish group's (Alef Null) code. This code runs on 

a Motorola 56K-based card and I am porting this to the new low cost 
Motorola EVM56K, which some of you may or not know about. I have had some 
good success and this effort now gives access to some great software 
contributions from the Alef Null group, in particular, Jarkko Vuori, 
OH2LNS. Pawel also has a wealth of good ideas that runs on M56K - I am just 
starting to appreciate some of it. 


A bit more about the EVM56K: It is a small card, about the size of a TI 
DSK, has a 56002 at 40 MHz, and 3 x 32K x 8 zero wait static ram. It uses a 


Crystal Semi CS4215 CODEC and in addition, has an optional FLASH EPROM that 
allows for making it a free-standing unit. The debugger that comes 

with it uses the 56002's built in hardware debugger, called the "OnCE" port, 
and is a powerful and non-intrusive hardware/software tool. It is different 
from the TI DSK in one respect, that the OnCE does not exsist as part of the 
DSP's application program. The debugger, however, operates through the PC's 
serial line at 19.2K - a bit slow for serious development work and too 

slow for doing some of the shared DSP/host applications that we have in 
mind. If you are a Motorola fan, this is a neat piece of hardware. 


For the moment, and at least for the forseeable future, there will be 
emphasis on the PSA-type sound cards and their closely-coupled architecture 
with the PC's resources, as well as the M56K architecture. Stay tuned to 
these projects if you are interested in low-level developments. 


I hope to be doing some work on the DSP-93 one of these days - though I 
am in great need of a faster intercommunication channel between the host 
and the DSP-93. If anyone has some ideas, please contact me in this regard. 


Keep up the good work, 73's 


--Johan, KC7WW 


From k5yfw@sacdm10.kelly.af.mil Tue Apr 18 15:20:50 1995 
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id PAAQQ690 for 
<hfsig@tapr.org>; Tue, 18 Apr 1995 15:20:42 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id m0s1Jjh-Q002BvC; Tue, 18 Apr 95 15:19 CDT 
Message-Id: <m0s1Jjh-Q002BvC@sacdm10.kelly.af.mil> 
Date: Tue, 18 Apr 95 15:19:01 -0500 
From: k5yf£w@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:392] HFSIG activities 
To: hfsig@tapr.org 
X-orig-date: Tue, 18 Apr 1995 13:35:34 -0500 
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu> 
X-orig-message-ID: <56CCA54471@frl.orst.edu> 


Johan, 


For those of us runing high speed TCP/IP on the AmpxrNet, I don't 
think anyone has found anything faster than the PI card. Its gonna 
be hard to beat a DMA card...a card plugged into the motherboard's 
bus, for speed. I believe that is part of the reason you originally 


went with the Soundwave and Cardinal cards. The Soundwave 32 can be 
bought on the surplus tables for less than $75 now. 


I see great benefit in off-loading some functions but keep one thing 
in mind...if we are ever to gain wide acceptance of this effort, we 
need to keep the effort within the confines of what computing power 
that is generally available to hams without too much additional 
hardware. This is why the Baycom is so popular. 


Keep up the good work. 
73 to all. 
Walt 


In your message of 18 Apr 1995 at 1335 CDT, you write: 
Hi All, 


A brief update: There are considerable amount of activity going on behind 
the scenes - this mostly has to with DSP specific stuff. Adrian, G4ZHZ, 
and Pawel, SP4VRC, both are making good progress. 


One reality that we have to deal with is that different DSP platforms are 
being used - understandable for good reasons. I am trying to stay involved 
by cross-porting where possible. For this reason, I have been working at 
porting some of the Finnish group's (Alef Null) code. This code runs on 

a Motorola 56K-based card and I am porting this to the new low cost 
Motorola EVM56K, which some of you may or not know about. I have had some 
good success and this effort now gives access to some great software 
contributions from the Alef Null group, in particular, Jarkko Vuori, 
OH2LNS. Pawel also has a wealth of good ideas that runs on M56K - I am just 
starting to appreciate some of it. 


A bit more about the EVM56K: It is a small card, about the size of a TI 

DSK, has a 56002 at 40 MHz, and 3 x 32K x 8 zero wait static ram. It uses a 
Crystal Semi CS4215 CODEC and in addition, has an optional FLASH EPROM that 
allows for making it a free-standing unit. The debugger that comes 

with it uses the 56002's built in hardware debugger, called the "OnCE" port, 
and is a powerful and non-intrusive hardware/software tool. It is different 
>from the TI DSK in one respect, that the OnCE does not exsist as part of the 
DSP's application program. The debugger, however, operates through the PC's 
serial line at 19.2K - a bit slow for serious development work and too 

slow for doing some of the shared DSP/host applications that we have in 
mind. If you are a Motorola fan, this is a neat piece of hardware. 


For the moment, and at least for the forseeable future, there will be 
emphasis on the PSA-type sound cards and their closely-coupled architecture 
with the PC's resources, as well as the M56K architecture. Stay tuned to 
these projects if you are interested in low-level developments. 


I hope to be doing some work on the DSP-93 one of these days - though I 
am in great need of a faster intercommunication channel between the host 
and the DSP-93. If anyone has some ideas, please contact me in this regard. 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV WV 


Keep up the good work, 73's 


VV VV WV 


--Johan, KC7WW 
> 
From FORRERJ@frl.orst.edu Wed Apr 19 12:32:28 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAAQ6944 for 
<HFSIG@tapr.org>; Wed, 19 Apr 1995 12:32:14 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA22700 for <HFSIG@tapr.org>; Wed, 19 Apr 1995 
02:31:34 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 19 Apr 95 10:37:54 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Apr 95 10:37:35 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Wed, 19 Apr 1995 10:37:35 PST8PDT 
Subject: DSP Platforms 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <6E1137374D@fr1l.orst.edu> 

Hi Walt, 

Just some further clarifaction on DSP platforms. 

For the kind of experimental work that we are doing, we need: 


a) sufficient DSP cycles (the more the better), 
b) sufficient bandwidth between the DSP platform and the PC. 


The latter is not 100% required, but allows for exploration of closely 
coupled DSP and PC algorithms. A good example would be to let the DSP do 
real-time convolution/correlation/FFT's and use Phil's Viterbi algorithm, 
running on the PC, to steer the DSP algorithms to achieve synchronization 
and error-control. Eventually, however, one would like that to be part of a 
free-standing system, but sure helps a lot if you have access to working 
code on a PC while your are in development phases. 


DMA is no real issue, however, a serial device working in the order of 115k 
or better, alternatively a high-speed parallel path is workable. 

DSP sound cards happen to offer this kind of interface, and with a bit of 
additional work, the DSP-93 or EVM56K and be made to do this too. 


It is my opinion that the DSP platform should not distract innovation, 
actually it adds a little "spice" to the effort - it would have been ideal 
if we all used the same hardware, but keep in mind that some of our ideas 
and contributions come from folks that do not have the financial 

means or access to technolgy that we take for granted. I think the 


appropiate thing to do is to let each use whatever they feel comfortable 
with - if it works, that is all that matters for the moment. However, in 
order to maintain some level of continuity, someone has to take on the task 
to port/translate ideas for further evaluation by others. The time 

will come when the technical details will be written up. I forsee a number 
of opportunities that will arise from that and help with that effort will be 
needed then. I guess it will be a while before we will have "turn key" 
systems - in the mean time, those that wish to be involved will have to 
roll up their sleeves and dig into the implementations themselves - its no 
simple task, but very educational, that is if one want to learn about how 
this technology works. These are exciting times. 


I forgot to mention the cost of the new EVM56K - it's only $150, 

really good value for what you get - available from authorized Motorola 
dealers. I will shortly make available a software package that makes the 
EVM56K compatible with the Alef Null project and thus allows access to 
their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600 
G3RUH, and DSP code for KISS/HDLC interfaces) . 


We keeping on looking for help with this SIG - someone to help write 
quaterly reports for PSR and help with running the SIG. Thanks. 


Remember also that TAPR membership supports this forum - if you are 
not yet a member of TAPR, kindly consider joining. 


73's - keep up the good work. 


Johan, KC7WW 
April, 1995 
From mamurphree@space.honeywell.com Wed Apr 19 13:59:34 1995 
Received: from £151mail.space.honeywell.com (f£151mail.space.honeywell.com 
[130.181.12.102]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id 
NAAO7539 for <hfsig@tapr.org>; Wed, 19 Apr 1995 13:59:30 -0500 
Received: from £151p01.space.honeywell.com by f151mail.space.honeywell.com with 
SMTP 

(1.38.193.5/16.2) id AA27504; Wed, 19 Apr 1995 15:03:28 -0400 
Received: by smtpdos.space.honeywell.com with Microsoft Mail 

id <2F958746@smtpdos.space.honeywell.com>; Wed, 19 Apr 95 14:57:26 PDT 
From: Murphree Michael A <mamurphree@space.honeywell.com> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:394] DSP Platforms 
Date: Wed, 19 Apr 95 14:57:00 PDT 
Message-Id: <2F958746@smtpdos.space.honeywell.com> 
Encoding: 13 TEXT 
X-Mailer: Microsoft Mail V3.0 


>I forgot to mention the cost of the new EVM56K - it's only $150, 

>really good value for what you get - available from authorized Motorola 
>dealers. I will shortly make available a software package that makes the 
>EVM56K compatible with the Alef Null project and thus allows access to 
>their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600 


>G3RUH, and DSP code for KISS/HDLC interfaces). 


Texas Instruments is again advertising their 3202X DSK board for $99 
as well. They do not identify exactly which processor the 2X is... 


Mike N4CNW 

From gjones@tenet.edu Sun Apr 23 21:39:46 1995 

Received: from Alice-Thurman.tenet.edu (Alice-Thurman.tenet.edu [198.213.2.5]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA12427; Sun, 23 Apr 1995 

21:39:39 -0500 

Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.11/8.6.9) id 

VAA14970; Sun, 23 Apr 1995 21:39:38 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199504240239.VAA14970@Alice-Thurman. tenet. edu> 

Subject: TAPR @ Dayton '95 

To: bbssig@tapr.org (BBS SIG mailing), netsig@tapr.org (NETSIG mailing), 
hfsig@tapr.org (HF SIG mailing), aprssig@tapr.org 

Date: Sun, 23 Apr 1995 21:39:38 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 3702 


TAPR Activities at Dayton '95 


Dayton is almost upon us and here is the list of TAPR activities and events 
happening during Dayton. We hope to see lots of folks around and please 
stop by the TAPR booth and say hi! 


TAPR Booth 

The booth is located at the same location as the last several years. We 
should have most items and kits available and another big membership offer 
will be available to new members! Come by and say hi to the TAPR gang and 
if you want, help out behind the table. The more the merrier. 


Regional Groups Note: If you are with a regional digital group, please stop 
by and chat with Greg Jones, WD5IVD about how TAPR can do things with your 
regional group. There will also be a place at the booth to place regional 
materials, so if you have something to hand out, drop it off. 


Friday - TAPR Digital Forum 

1:00pm - 1:45pm Introduction to Digital Communications 
Greg Jones, WD5IVD 

1:45pm - 2:00pm TAPR Update 
John Ackerman, AG9V 

2:00pm - 2:30pm Layer 1 and Radio Issues 
Mel Whitten, KOPFX 

2:30pm - 3:00pm TAPR/AMSAT DSP-93 Project Update 


Bill Reed, WDOETZ 
3:00pm - 3:30pm TCP/IP Issues and Trends 
Barry McLaren, VE3JF 
3:30pm - 3:45pm BBS Issues and Trends 
Barry Buelow, WAORIT 
3:45pm - 4:00pm HF Digital Communications Trends 


4:00pm - 4:30pm APRS 

Bob Bruninga, WB4APR 
4:30pm - 5:30pm TAPR APRS SIG 

Keith Sproul, WU2Z 


PACK*BASH T95 - Friday Evening 


A new event for the digitally-inclined ham, featuring: 

* Buffet dinner (with cash bar) 

x Nationally-known speakers holding forth on current topics: 
* Bob Bruninga, WB4APR (Author of APRS) 
*x Dewayne Hendricks, WA8DZP 

x Prize raffle 

x Lots of Informal Discussion 

* TAPR NET SIG and a second APRS SIG meeting 


When? 
Friday evening, April 28, 1995 
Dinner starts at 7:00 PM, speaker at 7:45 PM 
Everyone is invited to attend, but dinner is only available to those 
with reservations. 


Where? 
TJ's Restaurant, 2462 Dryden Road, Dayton 
(Dryden Road exit, I75 -- across from the Holiday Inn) 
(Maps available at the TAPR booth) 


How? 
Dinner requires advance registration (by April 24th) 
Come by the TAPR booth at Dayton to check on additional space. 
Everyone is invited to come, but dinner is only available to those 
with reservations. 
Dinner cost is $16.00 per person, tax and tip included. 


To register, contact: 
TAPR (tapr@tapr.org) 
Phone: (817) 383-0000, Fax: (817) 566-2544 


Who? 
PACKxBASH is co-sponsored by TAPR -- Tucson Amateur Packet Radio, 
the national leader in digital communication -- and the Miami 


Valley FM Association, Dayton's packet radio club. 


(This is a replacement of the McNasty's event) 


Saturday - BBS SIG Meeting 


The TAPR BBS SIG will meet Saturday night at 7:00pm 


Where: Radison Hotel - Premier Room 
The Radison is located near the intersection of I-75 and 
Needmore Rd. This is not far from Hara Arena. 


New feature this year - CHAIRS !!! 


This is a great opportunity to meet with fellow BBS Sysops and discuss 
current events and plans for the future. TAPR membership is not a 
requirement, this event is open to the public. 


For more information, stop by the TAPR booth at HARA. 


Tucson Amateur Packet Radio (tapr@tapr.org) 
8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 x 817-383-0000 


From paulr@hagar.udc.neweast.ca Mon Apr 24 06:58:37 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id GAA14826 for 

<hfsig@tapr.org>; Mon, 24 Apr 1995 06:58:33 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA26055; Mon, 24 Apr 95 11:58:28 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA798740923; Mon, 24 Apr 95 09:25:38 nst 

Date: Mon, 24 Apr 95 09:25:38 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 19 Text 

Message-Id: <9503247987 .AA798740923@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:395] RE: DSP Platforms 


>>>I forgot to mention the cost of the new EVM56K - it's only $150, 
>really good value for what you get - available from authorized Motorola 
>dealers. I will shortly make available a software package that makes the 
>EVM56K compatible with the Alef Null project and thus allows access to 
>their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600 
>G3RUH, and DSP code for KISS/HDLC interfaces). 


Texas Instruments is again advertising their 3202X DSK board for $99 
as well. They do not identify exactly which processor the 2X is... 


Mike N4CNW<< 


I'm fairly certain you can get the TMS320C5X DSK for $99. Its a fixed point DSP 
upgrade from the TMS320C26 (C25+bootloader) of the other DSK. 


Paul Russell 


From mamurphree@space.honeywell.com Mon Apr 24 07:57:49 1995 
Received: from £151mail.space.honeywell.com (f£151mail.space.honeywell.com 
[130.181.12.102]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id 
HAA15090 for <hfsig@tapr.org>; Mon, 24 Apr 1995 07:57:45 -0500 
Received: from £151p01.space.honeywell.com by f151mail.space.honeywell.com with 
SMTP 

(1.38.193.5/16.2) id AA23315; Mon, 24 Apr 1995 09:01:46 -0400 
Received: by smtpdos.space.honeywell.com with Microsoft Mail 

id <2F9BC9E4@smtpdos.space.honeywell.com>; Mon, 24 Apr 95 08:55:16 PDT 
From: Murphree Michael A <mamurphree@space.honeywell.com> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:397] RE: DSP Platforms 
Date: Mon, 24 Apr 95 08:56:00 PDT 
Message-Id: <2F9BC9E4@smtpdos.space.honeywell.com> 
Encoding: 31 TEXT 
X-Mailer: Microsoft Mail V3.0 


>>>>I forgot to mention the cost of the new EVM56K - it's only $150, 
>>really good value for what you get - available from authorized Motorola 
>>dealers. I will shortly make available a software package that makes the 
>>EVM56K compatible with the Alef Null project and thus allows access to 
>>their exsisting software (LPC, various noise filters, 1200 Bell 202, 9600 
>>G3RUH, and DSP code for KISS/HDLC interfaces). 

> 

>Texas Instruments is again advertising their 3202X DSK board for $99 

>as well. They do not identify exactly which processor the 2X is... 

> 

>Mike N4CNW<< 

> 

> 

> 

>I'm fairly certain you can get the TMS320C5X DSK for $99. Its a fixed point 
>DSP 

>upgrade from the TMS320C26 (C25+bootloader) of the other DSK. 

> 

>Paul Russell 

> 


Actually I have two of the 320C50 DSKs that I bought when they came out. 

The current ad is indicating the 20 series family though... I never saw any 
work done to translate some of the code available for the '20 DSK to the 

'5Q DSK. I started to do this myself some time ago, but have not found 
sufficient time to finish it. 


Mike N4CNW 


